[
https://issues.apache.org/jira/browse/CASSANDRA-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238637#comment-13238637
]
Brandon Williams commented on CASSANDRA-3937:
---------------------------------------------
bq. Firstly, is prepending the schema version string onto the existing output
likely to break any existing tooling ?
If someone is naively automating nodetool instead of using JMX itself, that is
their problem to solve, so I don't see a problem with this.
bq. Secondly, StorageProxy.decribeSchemaVersions() messages all live nodes in
the ring to find out their Schema versions. I thought that maybe this might be
a useful thing to expose via nodetool. Are there objections to adding nodetool
commands that require network comms?
I think this kind of violates nodetool's current philosophy (ala
CASSANDRA-2607) where it should do one thing against that machine only. If
someone wants to see all the versions they can automate nodetool quite easily.
> nodetool describering should report the schema version
> ------------------------------------------------------
>
> Key: CASSANDRA-3937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3937
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Brandon Williams
> Priority: Trivial
> Labels: lhf
> Fix For: 1.1.0
>
> Attachments:
> v1-0001-CASSANDRA-3937-Add-schema-version-to-nodetool-describe.txt
>
>
> Specifically to aid in debugging things like CASSANDRA-3931, now that you
> can't just decode the UUIDs to see which one has the higher timestamp.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
