[
https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064581#comment-13064581
]
Gary Dusbabek edited comment on CASSANDRA-1391 at 7/13/11 3:04 PM:
-------------------------------------------------------------------
Bottom line: we need to solve the problem of how to handle conflicts. I view
this as a similar problem of handling merge conflicts in change sets: a good
subset of the conflicts can be merged automatically because they are
independent of each other. But every once a while there is a conflict that
needs a manual edit-the solution is not computable because it isn't
deterministic.
This is currently addressed right now by strictly enforcing the relationship of
a migration with its predecessor to ensure that all migrations are applied
serially.
There is probably a pragmatic approach that I'm not able to see because the
merge-conflict problem makes it a non-starter for me.
was (Author: gdusbabek):
Bottom line: we need to solve the problem of how to handle conflicts. I
view this as a similar problem of handling merge conflicts in change sets: a
good subset of the conflicts can be merged automatically because they are
independent of each other. But every once a while there is a conflict that
needs a manual edit-the solution is not computable because it isn't
deterministic.
This is currently addressed right now by strictly enforcing the relationship of
a migration with its predecessor to ensure that all migrations are applied
serially.
There is probably a pragmatic approach that I'm able to see because the
merge-conflict problem makes it a non-starter for me.
> Allow Concurrent Schema Migrations
> ----------------------------------
>
> Key: CASSANDRA-1391
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1391
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Stu Hood
> Assignee: Gary Dusbabek
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira