[
https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181392#comment-13181392
]
Pavel Yaskevich commented on CASSANDRA-1391:
--------------------------------------------
bq. But then why do the patches still use thrift internally (I have only
quickly eyeballed the patches but it does seem to use thrift, which seems
confirmed by Jonathan comments).
Thrift is only used to keep current/new state of the ks/cf inside of the
migration to be used for diff upon apply, it doesn't really matter how we would
keep that - thrift, json, even comma separated plain text. I was guided by the
fact that we already use thrift internally and it makes it easy to get
attributes of the object when needed.
bq. Does that mean we still keep the list of all migrations (diffs) that have
ever been applied? If so, I would be in favor of getting rid of it, as it seems
to me we can do without (node could use the diffs between their schema and
another node schema and base whatever action have to be done (directories
creation, etc...) on that, be we wouldn't keep the diff afterwards).
I still don't get that huge deal why we need to re-implement migration logic
that way, what does it really gives us comparing to migrations? Migrations
already give as a straight way to tell a node what to do without involving any
schema transfers or decision making.
> 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:
> 0001-new-migration-schema-and-avro-methods-cleanup.patch,
> 0002-avro-removal.patch,
> 0003-oldVersion-removed-new-migration-distribution-schema.patch,
> 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
