[
https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189511#comment-13189511
]
Pavel Yaskevich commented on CASSANDRA-1391:
--------------------------------------------
bq. validateSchemaAgreement is unnecessary now right?
I think it's still a good idea to validate if all nodes have the same schema.
bq. the old Migration infrastructure feels unnecessarily heavyweight now. Can
we move the validation into the CassandraServer methods, and then just invoke a
MigrationHelper method from a runnable there?
I tried to optimize it as much as possible because I still think that there is
a reason to keep it because it encapsulates all announce, apply and validation
logic pretty good. I tried to move validation and stuff to the CassandraServer
but it shows itself as hardly readable and heavy-weight.
bq. should we snapshot the old avro schema before nuking it?
MigrationHelper.dropColumnFamily that I call to remove Migrations and Schema
CFs makes snapshot of the data.
bq. SystemTable.dropOldSchemaTables is a no-op. I think we can take this out
entirely since loadSchema/fromAvro takes care of it?
Ugh, I forgot to remove it from the final version of the patch, sorry...
bq. Can you add a comment describing the layout of the new schema CFs to
defstable or systemtable?
Sure, I will do that in SystemTable.
bq. I'd prefer to leave the low level slicing / deserialize in SystemTable
class instead of scattered between Schema and DefsTable
Sure, I will move serialize and serialized methods from Schema to SystemTable,
plus DefsTable.readSchemaRow and getSchema also go there.
> 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
> Priority: Critical
> Fix For: 1.1
>
> Attachments: 1391-rebased.txt, 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
