cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jorge Bay (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7679) Batch DDL
Date Tue, 13 Jan 2015 14:15:35 GMT


Jorge Bay commented on CASSANDRA-7679:

Consider the example using any driver with a round robin policy:
session.execute("CREATE TABLE tbl1 ...");
session.execute("INSERT INTO tbl1...");

In a multinode cluster, this will fail. [This includes any getting started example that you
can find|].
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:
>             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
> 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

View raw message