cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Pushing Cassandra 1.2 back a month to November?
Date Tue, 25 Sep 2012 17:16:07 GMT
We are more or less on track for the promised late October 1.2 release
[1] but I'm starting to think we should expand the scope of 1.2 a bit
to get cql3 and the corresponding binary protocol truly "right."

Specifically,
1) We'd like to move the consistency level setting from the CQL
language to the protocol level.
2) The binary protocol only really has a Java implementation so far.
Having the time to flesh out the Python implementation would be a good
sanity check before we commit to protocol stability.

Additionally,
3) vnodes is a big change that could use more time to test.  I'd like
to avoid a repeat of the schema change mess from 1.1, where we did a
substantial rewrite that took six minor releases to get all the bugs
out of.

Gory details on the CQL situation:

Currently, in CQL3, you set the consistency level of an operation in
the language, eg 'SELECT * FROM foo USING CONSISTENCY QUORUM'.  It now
looks like this was a mistake, and that consistency should be set at
the protocol level, i.e. as a separate parameter along with the query.

The reasoning is that the CL applies to the guarantee provided by the
operation being successful, not to the query itself.  Specifically,
having the CL being part of the language means that CL is opaque to
low level client libraries without themselves parsing the CQL, which
we want to avoid.  Thus,

    - Those libraries can't implement automatic retries policy, where a query
      would be retried with a smaller CL.  (I'm aware that this is often a
      Bad Idea, but it does have legitimate uses and not having that available
      is seen as a regression from the Thrift api.)
    - We had to introduce CASSANDRA-4448 to allow the client to configure some
      form of default CL since the library can't handle that anymore, which is
      hackish.
    - Executing prepared statements with different CL requires preparing
      multiple statements.
    - CL only makes sense for BATCH operations as a whole, not the
      sub-statements within the batch. Currently CQL3 "fixes" that by
      validating the given CLs match, but it would be much more clear
      if the CL was on the protocol side.

Moving the CL to the protocol level solves all of that but the problem
is, if we move the CL from the language to the protocol after 1.2,
that's a breaking change of CQL3, so we're talking CQL4.  Bad idea.

[1] although later-than-planned freeze is a warning sign

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Mime
View raw message