[
https://issues.apache.org/jira/browse/CASSANDRA-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026698#comment-13026698
]
Jonathan Ellis commented on CASSANDRA-2536:
-------------------------------------------
bq. A node shouldn't accept a schema change if the timestamp for the new schema
would be earlier than its current schema.
You need this with or without the client-side timestamp, though; there's no
sense in letting people blow their leg off.
And once you have that you don't need to add a client-side timestamp with all
the PITA-ness that involves.
(And unlike with data modification, I can't think of a use for doing "clever"
things w/ a client side timesamp. So pushing it to the client doesn't really
solve anything, just means you need to sync clocks across more machines.)
> Schema disagreements when using connections to multiple hosts
> -------------------------------------------------------------
>
> Key: CASSANDRA-2536
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2536
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.8 beta 1
> Environment: Two node 0.8-beta1 cluster with one seed and JNA.
> Reporter: Tyler Hobbs
> Assignee: Tyler Hobbs
> Attachments: schema_disagree.py
>
>
> If you have two thrift connections open to different nodes and you create a
> KS using the first, then a CF in that KS using the second, you wind up with a
> schema disagreement even if you wait/sleep after creating the KS.
> The attached script reproduces the issue using pycassa (1.0.6 should work
> fine, although it has the 0.7 thrift-gen code). It's also reproducible by
> hand with two cassandra-cli sessions.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
