[
https://issues.apache.org/jira/browse/CASSANDRA-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230578#comment-13230578
]
Sylvain Lebresne commented on CASSANDRA-4017:
---------------------------------------------
The reason is that when we compute for a migration what has changed, we do that
based on the on-disk schema. So calling only Schema.load() means that the
on-disk schema is empty and thus some test of DefsTast that try to modify a CF
are not recognized as updates but as add and fail (since the cf exists in
memory).
Now, an option could be to compute 'what has changed' based on the in-memory
schema. However, even if we do that (I honestly don't have much argument for
doing it or not doing it, but pleasing the unit tests seems like the worst
possible reason to do it), I think it is still nice to use the normal path
(i.e. not only load in memory with Schema.load()) to load the test schema
because that means we exercise that code which is a good thing and make our
unit tests less 'fake'. I'll note for instance that the patch fix a small bug
in the current code that serialize/deserialize schema that was caught once I
started writing the test schema on-disk but wasn't previously.
> Unify migrations
> ----------------
>
> Key: CASSANDRA-4017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4017
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Jonathan Ellis
> Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
>
> Now that we can send a schema as a RowMutation, there's no need to keep
> separate add/drop/update migration classes around. Let's just send the
> schema to our counterparts and let them figure out what changed. Currently
> we have "figure out what changed" code to both generate migrations on the
> sender, and for application on the target, which adds complexity.
--
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
