[
https://issues.apache.org/jira/browse/CASSANDRA-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275227#comment-14275227
]
Jorge Bay commented on CASSANDRA-7679:
--------------------------------------
Consider the example using any driver with a round robin policy:
{code:java}
session.execute("CREATE TABLE tbl1 ...");
session.execute("INSERT INTO tbl1...");
{code}
In a multinode cluster, this will fail. [This includes any getting started
example that you can
find|http://www.datastax.com/documentation/developer/java-driver/2.1/java-driver/quick_start/qsSimpleClientAddSession_t.html].
I don't think its a good idea to force users to wait an undetermined amount of
time (even if its small) for them to be sure that the schema change was applied
in the cluster. This prevents tools similar to Rails Migrations (as a general
pattern) to be used with C*.
IMO, the "batching" (allowing multiple schema changes in one request) is not as
important as allowing users know that the schema change was applied in the
cluster.
> Batch DDL
> ---------
>
> Key: CASSANDRA-7679
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7679
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Robert Stupp
>
> Just an idea: To improve speed of DDL in clusters with lots of
> Keyspaces/Tables/Columns it might help to collect a bunch of schema changes
> and propagate them as a single bunch of changes.
> Such a DDL batch would
> # execute DDLs locally and collect all mutations
> # broadcast all mutations at once
> # schema agreement
> # return list<SchemaChange> via native protocol to the client
> So {{DefsTables.mergeSchemaInternal}} (which seems to be the expensive part)
> would only execute once per DDL batch on each node.
> DDL batches would not be atomic.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
