[GitHub] [cassandra] iamaleksey commented on a diff in pull request #1639: Cassandra 17647

[GitBox <gi...@apache.org>]

iamaleksey commented on code in PR #1639:
URL: https://github.com/apache/cassandra/pull/1639#discussion_r882457168


##########
src/java/org/apache/cassandra/cql3/statements/schema/AlterKeyspaceStatement.java:
##########
@@ -76,6 +78,9 @@ public Keyspaces apply(Keyspaces schema)
 
         KeyspaceMetadata newKeyspace = keyspace.withSwapped(attrs.asAlteredKeyspaceParams(keyspace.params));
 
+        if (attrs.getReplicationStrategyClass() != null && attrs.getReplicationStrategyClass().equals(SimpleStrategy.class.getSimpleName()))

Review Comment:
   So, the `CREATE` case is pretty obvious. With `ALTER`, however, I wonder - should we allow altering the replication factor on a table that has had `SimpleStrategy` enabled prior to its prohibition by guardrails?
   
   In other words, if current strategy is `SimpleStrategy` should we still allow such an alter? Some system keyspaces are created with `SimpleStrategy` - and are expected to be RF-changed by the user to a cluster-size appropriate RF. Should we allow upping it if the guardrail is on - while keeping it on `SimpleStrategy`?
   
   I'm leaning towards interpreting the guardrail on as "don't allow `ALTER` to *switch* to `SimpleStrategy`", myself. WDYT?



-- 
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-unsubscribe@cassandra.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: pr-unsubscribe@cassandra.apache.org
For additional commands, e-mail: pr-help@cassandra.apache.org