beobal commented on code in PR #3967:
URL: https://github.com/apache/cassandra/pull/3967#discussion_r1992081970
##########
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 don't know if there is a usual approach. Certainly in CEP-21 we tried to
ensure we didn't modify any existing system tables to preserve whatever
downgradability was previously possible. Fortunately, we didn't really need to
touch existing tables and I wonder whether this actually needs to either. The
new field should be durable due to the metadata and log serialization and of
course it isn't relevant to downgrades. As far as I remember the only other
reasons for keeping the system_schema tables around and updated are for drivers
(which I imagine have no need to know about this new field) and for manual
inspection (i.e. querying them in cqlsh etc).
Ideally, we should migrate system_schema to a virtual keyspace, for which we
have https://issues.apache.org/jira/browse/CASSANDRA-19129
There was some discussion around this recently, first on
https://issues.apache.org/jira/browse/CASSANDRA-20331 and then on the dev list
https://lists.apache.org/thread/j69c7d2vtn9h5v4rvy3w0kr563h2n7m5
--
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]
