Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of driftx@gmail.com designates
 209.85.212.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALdd-zjXtwT2hXDbPithL2oszM8HN80BG+0tnkSmzTo0Z02SOg@mail.gmail.com>
References: 
 <CALdd-zjXtwT2hXDbPithL2oszM8HN80BG+0tnkSmzTo0Z02SOg@mail.gmail.com>
From: Brandon Williams <driftx@gmail.com>
Date: Wed, 26 Sep 2012 08:22:57 -0500
Message-ID: 
 <CAAafH9S18v904cTY0YJ+-R5Zn8eyRGi=LrxzHnPmJYDyT-ZJgQ@mail.gmail.com>
Subject: Re: Pushing Cassandra 1.2 back a month to November?
To: dev@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1

+1

The vnode troubleshooting process has been rough, so I'm all for more
testing there.

On Tue, Sep 25, 2012 at 12:16 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
> 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