Allow setting key/value in a metadata stored in the topology#5103
Conversation
cdfdfac to
aa73834
Compare
aa73834 to
d4f59c0
Compare
d4f59c0 to
99eb8b7
Compare
go/vt/topo/metadata.go
Outdated
There was a problem hiding this comment.
I'd add a little comment at the end like // Can never fail.
go/vt/vtgate/executor.go
Outdated
There was a problem hiding this comment.
Use a switch here now that you have >1 case?
go/vt/vtgate/executor_test.go
Outdated
There was a problem hiding this comment.
It seems to be used only in one test go/vt/vtgate/engine/ordered_aggregate_test.go
There was a problem hiding this comment.
Yeah, I just introduced it, and used it on the code I was working on at the time. You can and should definitely use it. :)
There was a problem hiding this comment.
Done. Used in the new tests
go/vt/vtgate/executor.go
Outdated
There was a problem hiding this comment.
I'd use len(metadata) as the capacity here.
go/vt/vtgate/executor_test.go
Outdated
There was a problem hiding this comment.
oh I didn't know the variables keyword. I assume this is "standard"?
There was a problem hiding this comment.
Yes, wanted to keep same syntax
SHOW [GLOBAL | SESSION] VARIABLES
[LIKE 'pattern' | WHERE expr]
go/vt/vtgate/executor.go
Outdated
There was a problem hiding this comment.
You're still passing in the keyspace here?
go/vt/vtgate/executor.go
Outdated
There was a problem hiding this comment.
I think you're not using ksName?
a8b2f6c to
de15fda
Compare
go/vt/vtgate/executor.go
Outdated
There was a problem hiding this comment.
@dweitzman I've made changes to use vschemaacl to authorize specific users to execute "set vitess_metadata" actions. This works for our current requirements but a separate PR will separate this into its own metadataacl definition. Trying to keeps this PR small
de15fda to
a25abf2
Compare
demmer
left a comment
There was a problem hiding this comment.
Overall this LGTM -- one minor comment but I'm happy with this syntax and approach.
go/vt/topo/metadata.go
Outdated
There was a problem hiding this comment.
Are we 100% sure this is a compatible conversion from the LIKE syntax to regexp? Itt's fine for this use case but if there's a more robust and generic way to do this, we might get some mileage out of making it a common function in the Vitess code base.
There was a problem hiding this comment.
I found this link with examples of the LIKE syntax: https://www.w3schools.com/sql/sql_like.asp
I we also need to support _.
I agree that extracting a "LIKE to regexp" converter into a separate file and a more shared place and then writing specific unit tests for that would be nice. I'm not sure we need to make that 100% compliant in this PR though. We can iterate on that once we have it in a central place with a nice suite of unit tests.
There was a problem hiding this comment.
Extracted functionality to separate file with unit tests. Also supporting '_' character and escaping using ""
40b7aef to
3bc0486
Compare
Signed-off-by: Karel Alfonso Sague <kalfonso@squareup.com>
3bc0486 to
453d54b
Compare
sougou
left a comment
There was a problem hiding this comment.
We also need the ability to delete metadata. How about we treat an empty value as a delete?
| KeyspacesPath = "keyspaces" | ||
| ShardsPath = "shards" | ||
| TabletsPath = "tablets" | ||
| MetadataPath = "vitess_metadata" |
There was a problem hiding this comment.
Hope it's not too late. This should be just metadata, just like we didn't prefix the other paths with vitess_.
There was a problem hiding this comment.
It's not too late. This is the path in zk right? Yes I agree this should be just metadata not vitess_metadata. The syntax should be SET @@vitess_metadata though just like all of our other SQL extensions. Right?
There was a problem hiding this comment.
Yes. We don't want collisions in the variable name.
This PR allows setting key/value metadata in the topology leveraging "set" & "show" SQL statements.
Signed-off-by: Karel Alfonso Sague kalfonso@squareup.com