adelapena commented on code in PR #2391:
URL: https://github.com/apache/cassandra/pull/2391#discussion_r1222919398
##########
src/java/org/apache/cassandra/config/DatabaseDescriptor.java:
##########
@@ -1424,9 +1425,20 @@ private static void
validateSSTableFormatFactories(Iterable<SSTableFormat.Factor
if (selectedFormat == null)
throw new ConfigurationException(String.format("Selected sstable
format '%s' is not available.", selectedFormatName));
+ validateWriteFormatVsStorageCompatibilityMode(selectedFormat,
getStorageCompatibilityMode());
+
return selectedFormat;
}
+ @VisibleForTesting
+ public static void
validateWriteFormatVsStorageCompatibilityMode(SSTableFormat<?, ?>
selectedFormat, StorageCompatibilityMode mode)
+ {
+ if (selectedFormat.name().equals(BtiFormat.NAME) && mode !=
StorageCompatibilityMode.NONE)
Review Comment:
That situation, being able to support new features during rolling upgrades,
is not new. I don't think that offering the possibility of running in
compatibility mode changes it. IMO it doesn't remove the need of having the
rolling upgrade dtests that we usually add to prevent multiplexing entire CI.
For the scope of this ticket, I think we can assume that tries work in rolling
upgrade mode, since that was the assumption when they were merged.
--
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: pr-unsubscr...@cassandra.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: pr-unsubscr...@cassandra.apache.org
For additional commands, e-mail: pr-h...@cassandra.apache.org
