[prototype] sql: add system.span_configurations for kv span configs#66402
Conversation
4d6d8b4 to
1a9932a
Compare
Fixes cockroachdb#66390. It's not wired up to anything yet; we'll later use this system-tenant only table to store KV span configs. Release note (sql change): We've added a `system.span_configurations` table. This will later be used to store authoritative zone configs that KV has decided to apply.
1a9932a to
49eae54
Compare
arulajmani
left a comment
There was a problem hiding this comment.
@ajwerner did you have concerns about merging this to master or do we feel comfortable enough to do so after todays pod meeting?
Reviewed 32 of 32 files at r1.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @ajwerner)
|
Wait, are we clear on the protocol yet? I feel like there's definitely details we want ironed out. I really don't want to see a table without the code that exercises it. I'd much much prefer the interfaces for the layers merging first with an in-memory map that can be hooked into an in-memory cluster before the new SQL tables. I have a distinct fear of prototypes which are developed and hooked up to communicate through durable state in SQL tables. We should be hiding that all underneath some storage abstraction for the KV layer. I'd also love more clarity on what the protobufs are going to look like that live in this table. |
|
Let me catch up on the RFC. I still think it'd be better to lead off this project by merging interfaces which can be used for testing the reconciliation layer and for testing the server side. What interface will Mostly though, I don't see much value in adding the tables without code to exercise them. |
|
@ajwerner and I discussed internally around wanting to first spell out the interfaces and then back them up by these concrete implementations that actually write state, vs. coming up with these concrete implementations first and then finding out the abstract interfaces to wrap around them. I think in the short term Arul and I are likely going to work on a short-lived branch to figure out what these interfaces are and how they should fit with the surrounding code, later we'll start merging the earlier revisions in this branch back to master. So we'll mark these PRs with the [prototype] prefix, have them land against the |
system.span_configurations for kv span configssystem.span_configurations for kv span configs
Fixes #66390. It's not wired up to anything yet; we'll later use this
system-tenant only table to store KV span configs.
Release note (sql change): We've added a
system.span_configurationstable. This will later be used to store authoritative zone configs that
KV has decided to apply.