[
https://issues.apache.org/jira/browse/CASSANDRA-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15116229#comment-15116229
]
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: https://issues.apache.org/jira/browse/CASSANDRA-10699
> 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
(v6.3.4#6332)
