cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5886) Provide a propagation guarantee for DDL queries execution
Date Tue, 20 Aug 2013 10:53:52 GMT


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:
>             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
> 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:

View raw message