[jira] [Commented] (CASSANDRA-7679) Batch DDL

["Jorge Bay (JIRA)" <ji...@apache.org>]

    [ 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)