[ https://issues.apache.org/jira/browse/CASSANDRA-16048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179691#comment-17179691 ]
Sylvain Lebresne commented on CASSANDRA-16048: ---------------------------------------------- Not to reject this upfront completely, but wanted to note that a part of me wonders if this is a good idea. First, I feel this murky the waters a bit around the upgrade path to 4.0. "You have to run {{DROP COMPACT STORAGE}} on all compact table before upgrading" is a simple rule. Simple is good, and I feel adding special cases is adding confusion. And the upside here is pretty minor. Of course, we could leave this undocumented, and keep only the simple rule in all documentation. But if we don't document this, I think this create a risk of surprising users, which is my other point. Because it's not 100% true that "there is no visible change to the user facing schema after dropping compact storage". The schema of those tables loses the {{WITH COMPACT STORAGE}} (and the {{system_schema}} table will lose the {{DENSE}} flag, which is also technically visible). Which may sound trivial, but it's a bit hard to ensure that there no user tool/code out there that rely on it. And in general, users may simply be confused that their table appears to lose a property silently, or wonder why the schema dump of that table done on 3.x does not replay properly on 4.0 anymore. Tbc, I get how for "us", devs of C* that understand the internals, it sounds annoying to have to run a command when we know it could be done automatically and we're not gonna be confused by it. Just not sure this is a good place to optimize for "us". > Safely Ignore Compact Storage Tables Where Users Have Defined Clustering and > Value Columns > ------------------------------------------------------------------------------------------ > > Key: CASSANDRA-16048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16048 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL > Reporter: Jordan West > Assignee: Jordan West > Priority: Normal > Fix For: 4.0-beta > > > Some compact storage tables, specifically those where the user has defined > both at least one clustering and the value column, can be safely handled in > 4.0 because besides the DENSE flag they are not materially different post 3.0 > and there is no visible change to the user facing schema after dropping > compact storage. We can detect this case and allow these tables to silently > drop the DENSE flag while still throwing a start-up error for COMPACT STORAGE > tables that don’t meet the criteria. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org