cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack Krupansky (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10699) Make schema alterations strongly consistent
Date Mon, 25 Jan 2016 22:49:40 GMT


Jack Krupansky commented on CASSANDRA-10699:

Will resolution of this ticket enable concurrent clients to successfully perform CREATE TABLE
IF NOT EXISTS? Or will that still be problematic? I just want to know if this is the ticket
to point people to for concurrent CREATE TABLE IF NOT EXISTS issues.

In the mean time, should we update the doc to effectively say that concurrent CREATE TABLE
IF NOT EXISTS is not supported and that it is the responsibility of the user to absolutely
refrain from attempting any potentially concurrent attempts to CREATE TABLE IF NOT EXISTS
for a given table?

A related doc issue is how the user can tell that the CREATE TABLE has successfully completed
around the ring. IOW, if cqlsh returns success, is the table really created on all nodes?
Is a nodetool tablestats a reliable check - if all nodes are listed then the CREATE TABLE
has succeeded/completed on all nodes?

> Make schema alterations strongly consistent
> -------------------------------------------
>                 Key: CASSANDRA-10699
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: Aleksey Yeschenko
>             Fix For: 3.x
> Schema changes do not necessarily commute. This has been the case before CASSANDRA-5202,
but now is particularly problematic.
> We should employ a strongly consistent protocol instead of relying on marshalling {{Mutation}}
objects with schema changes.

This message was sent by Atlassian JIRA

View raw message