[
https://issues.apache.org/jira/browse/CASSANDRA-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744847#comment-13744847
]
Sylvain Lebresne commented on CASSANDRA-5886:
---------------------------------------------
The current status quo is that it's the burden of the client (driver) to check
for schema agreement. Which can be done (with as much accuracy that could be
done in Cassandra) using the schema versions that is exposed in the system
table (though I'll note that CASSANDRA-5904 makes it slightly racy currently,
which will be fixed).
Of course, there's the question of whether it could be better to do that schema
agreement check Cassandra side (we actually used to do it back in the days)
before returning from a DDL (which I think, is the right way to do it: adding
the check on error in DML is imo more hacky (but I have no clue what
"partition" means in your description so maybe I didn't understood the
suggestion)). On the one side, doing it Cassandra side avoid having each client
driver re-implementing the check (a good thing), but on the other side, such
check is bound to not be perfect (with node failures) and leaving it client
side allows the client driver to return more meaningful information to the user
on this process when something is wrong, and allow for the option to not wait
if that's relevant for the client.
Overall, I don't think this is horribly hard to implement for client drivers,
so I'd be in favor of leaving it as it is. I'm certainly open to discussion
though.
> Provide a propagation guarantee for DDL queries execution
> ---------------------------------------------------------
>
> Key: CASSANDRA-5886
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5886
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Michaël Figuière
> Priority: Minor
>
> Currently schema modifications are not guaranteed to be propagated when the
> DDL statement's response reach the client. While this is not a drama, it
> appears to be annoying when writing integration tests for an application for
> instance. Additionally this behaviour gives a feel of brittleness to
> newcomers who meet a "Table does not exist" error on a table that they've
> just created.
> A possible workaround would be for the coordinator to wait for at least one
> replica of each partition to acknowledge a DDL query. Then when a node meets
> a schema error on a DML query it could contact the other replicas for one of
> the token it owns to check for schema updates.
> Doing so would make DDL queries and DML queries with schema errors slower but
> it doesn't matter as performances of the former are not critical (and the
> response time would still be reasonable as we wait only for the fastest
> replica of each partition to answer) and the latter are not expected to
> happen in stable production environments.
> The guarantee would not be absolute as all of the nodes for a given partition
> might be down/not answer on time. But doing so we would make the error much
> more unlikely to happen. And we'll always have the possibility to increase
> the amount of partitions to contact in the case of DML schema errors...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
