All right. With no dissenting opinions, let's make this the new plan of record.
I've created https://issues.apache.org/jira/browse/CASSANDRA-4734 for the protocol change; let's get that into beta2 and take it from there. On Wed, Sep 26, 2012 at 8:22 AM, Brandon Williams <dri...@gmail.com> wrote: > +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 <jbel...@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 -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
