beobal commented on code in PR #3967:
URL: https://github.com/apache/cassandra/pull/3967#discussion_r1993246046
##########
src/java/org/apache/cassandra/schema/SchemaKeyspace.java:
##########
@@ -140,6 +140,7 @@ private SchemaKeyspace()
+ "clustering_order text,"
+ "column_name_bytes blob,"
+ "kind text,"
+ + "unique_id int,"
Review Comment:
> I think the main thing is that the uids are all assigned on the same
version of the metadata
Doing it with a transformation would ensure this, no?
> Perhaps it makes sense to have an "upgraded" epoch, that is issued by CMS
to allocate these ids.
Maybe I'm misunderstanding, but that would be the epoch of the
transformation that allocates the uids. So if we need to prevent "regular" DDL
transformations (create/alter table) from assigning uids until after that has
been enacted, then we just make its effect easily visible, e.g. a flag on
ClusterMetadata.schema or something to indicate whether or not to assign uids.
AFAICT this is only a consideration in the window between the first node
being upgraded to a version which knows about column uids & the transform to
allocate them being committed. Maybe it's not even a concern then either, if we
modify the second part of the trigger to be "any table has columns without
uids" & have the transformation respect existing non-default uids (i.e. those
allocated by a create/alter during that window).
##########
src/java/org/apache/cassandra/schema/SchemaKeyspace.java:
##########
@@ -140,6 +140,7 @@ private SchemaKeyspace()
+ "clustering_order text,"
+ "column_name_bytes blob,"
+ "kind text,"
+ + "unique_id int,"
Review Comment:
> I think the main thing is that the uids are all assigned on the same
version of the metadata
Doing it with a transformation would ensure this, no?
> Perhaps it makes sense to have an "upgraded" epoch, that is issued by CMS
to allocate these ids.
Maybe I'm misunderstanding, but that would be the epoch of the
transformation that allocates the uids. So if we need to prevent "regular" DDL
transformations (create/alter table) from assigning uids until after that has
been enacted, then we just make its effect easily visible, e.g. a flag on
ClusterMetadata.schema or something to indicate whether or not to assign uids.
AFAICT this is only a consideration in the window between the first node
being upgraded to a version which knows about column uids & the transform to
allocate them being committed. Maybe it's not even a concern then either, if we
modify the second part of the trigger to be "any table has columns without
uids" & have the transformation respect existing non-default uids (i.e. those
allocated by a create/alter during that window).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
