[
https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149875#comment-13149875
]
Jonathan Ellis commented on CASSANDRA-1391:
-------------------------------------------
Here is one way to model it:
*keyspaces*
{noformat}
name: { // key
'durable_writes': bool,
'replication_strategy' : { // composite columns ahead!
'class': str,
'options': {
// strat-dependent options
}
}
}
Example (w/ composite names spelled out):
'Keyspace1': {
'durable_writes': True,
('replication_strategy', 'class'): 'SimpleStrategy',
('replication_strategy', 'options', 'replication_factor'): 1
}
{noformat}
*columnfamilies*
{noformat}
name: { // key
'keyspace': str,
'comparator': str,
...
'columns': { // composite!
column name: {
'validation_class': str,
'index_type': str,
'index_name': str,
'index_options': { }
}
}
}
{noformat}
Since each option is its own column, we leverage Cassandra's own conflict
resolution: it's easy to see how if client 1 changes Keyspace1.durable_writes
to False, and another client changes replication_strategy to NTS, there is no
conflict and life is good. But if one changes r_s to NTS and another changes
it to ONTS, then the one w/ higher timestamp wins. This is important to
tolerate different nodes receiving the changes in different orders, which is
necessary for everyone to end up in the same state.
> Allow Concurrent Schema Migrations
> ----------------------------------
>
> Key: CASSANDRA-1391
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1391
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.7.0
> Reporter: Stu Hood
> Assignee: Pavel Yaskevich
> Fix For: 1.1
>
> Attachments: CASSANDRA-1391.patch
>
>
> CASSANDRA-1292 fixed multiple migrations started from the same node to
> properly queue themselves, but it is still possible for migrations initiated
> on different nodes to conflict and leave the cluster in a bad state. Since
> the system_add/drop/rename methods are accessible directly from the client
> API, they should be completely safe for concurrent use.
> It should be possible to allow for most types of concurrent migrations by
> converting the UUID schema ID into a VersionVectorClock (as provided by
> CASSANDRA-580).
--
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
