Adding to Hari's comments: > Any changes expected at client/driver side? While using JMX/nodetool, it is > clear that the command/operations are getting executed against which > Cassandra node. But a client can connect to multiple hosts and trigger > queries, then how can it ensure that commands are executed against the > desired Cassandra instance?
Clients are expected to set the node for the given CQL statement in cases like this; see docstring for example: https://github.com/apache/cassandra-java-driver/blob/4.x/core/src/main/java/com/datastax/oss/driver/api/core/cql/Statement.java#L124-L147 > The term COMMAND is a bit abstract I feel (subjective). Some of the examples > quoted are referring to updating settings (for example: EXECUTE COMMAND > setconcurrentcompactors WITH concurrent_compactors=5;) and some are referring > to operations. Updating settings and running operations are considerably > different things. They may have to be handled in their own way. And I also > feel the settings part is overlapping with virtual tables. If virtual tables > support writes (at least the settings virtual table), then settings can be > updated using the virtual table itself. I agree with this - I actually think it would be clearer if this was referred to as nodetool, if the set of commands is going to be largely based on nodetool at the beginning. There is a lot of documentation online that references nodetool by name, and changing the nomenclature would make that existing documentation harder to understand. If a user can understand this as "nodetool, but better and over CQL not JMX" I think that's a clearer transition than a new concept of "commands". I understand that this proposal includes more than just nodetool, but there's a benefit to having a tool with a name, and a web search for "cassandra commands" is going to have more competition and ambiguity.
