cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Evans (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2474) CQL support for compound columns and wide rows
Date Sun, 15 Jan 2012 00:33:41 GMT


Eric Evans commented on CASSANDRA-2474:

bq. First, let's be clear about our priorities here. While backwards compatibility is an important
consideration, it is not a guarantee we have made for CQL, nor should we at this stage in
its development.

It's not about guarantees, it's about _expectations_.

Interface stability was _the_ motiviating factor behind CQL.  Other arguments became obvious
later, yes, but that was what set the whole thing in motion.  It was born out of requirements
that my employer at the time had, and it was the reason they paid me to do the initial work.

Since then I've been very vocal about interface stability in every forum.  It's a message
that has resonated extremely well, and something that seemed to have consensus within the
project; If I was speaking out of turn, no one stepped in to tell me.

TL;DR The absence of an iron-clad guarantee doesn't mean that breakage isn't unwanted, or
won't come as a surprise. Breaking the language now (with plans already laid to break it again
in 1.2) exceeds my expectations, and I know it exceeds others.

As Eric points out, we have made breaking changes deliberately before, because updating the
language to add missing functionality made clear where we'd gotten something wrong. Expecting
anything else from a partially finished language is totally unrealistic.

Keep in mind as well that maintaining deprecated features indefinitely is a resource sink
that we can ill afford. We have a relatively small set of active developers, and time spent
working around code supporting obsolete features, perhaps fixing regressions caused by keeping
it alive, is time we can ill afford. Unlike Thrift, where methods live in relative isolation
in CassandraServer, everything in the CQL parser and QueryProcessor is intertwined. So there
is a higher price to pay than you may realize.

Of course there is a balance to strike, and a cost to pay for maintaining backward compatibility.
 But, we've used this argument for years and IMO people are starting to expecting more from
us now.

But the longer we go before making necessary changes and finishing things, the more painful
that will get. So, to Eric's point, better to make these changes now -- which I've been promising
in public since at *least* Cassandra SF, so I don't think it's valid to cry end-of-release
foul -- than to make them for the 1.2 transition, when presumably more people will have deployed
on CQL.

I'm crying foul because we're proposing to break the language very late in the game.  How
often people are expecting CQL to break notwithstanding, anyone who has been trying to plan
their projects around what they expect to land in 1.1 are in for a surprise.  If no one is
making such plans, then perhaps it's because they've given up trying.  Either way it's not

Doing this so late in the game, also increases the likelihood that something will be missed
and that things will need to change again later.

And I'm crying foul because this ticket was contentious and required a lot of discussion to
reach consensus (which I am _very_ thankful of when looking back at what might have been implemented
otherwise), and yet it seems we're all too ready to pull the trigger on this potentially controversial
"errata" without taking it to the wider community.

I know this is publicly available, but you'd be hard pressed to do a better job of obfuscating
a discussion than having it in the comments of this issue.

Let me elaborate. We're not actually removing functionality here. The new-style definition

   key <type1> PRIMARY KEY,
   column <type2>,
   value <type3>

gives you the same freedom of using arbitrary column names as an old-style declaration with
a comparator of type2. The difference is, this definition allows CQL queries to know how to
turn the column name into a resultset value, allowing it to be used in more flexible {{WHERE}}
clauses than {{..}}, as well as allowing use in paging across multiple rows (necessary for
wide-row map/reduce support).

So, we're not taking away the flexibility to use column names at run time for non-composite
columns; just requiring that if you want to use a CF in a dynamic, wide-row way, you tell
us about it so we can support you appropriately.  (Knowing when a CF is "wide row oriented"
also opens up new optimization possibilities, from simple ones like skipping the row-level
bloom filter to fancier ones like CASSANDRA-3581.)

What is the effect on users with an existing schema?

Hmm. I'm not sure if you misread what he said and thought he's changing it to case-sensitive,
or if you think case-sensitive is how it behaves now. Or maybe something else entirely. :)

Currently, column names are case *insensitive*, (see QueryProcessor.getColumnNames), and so
are row keys (WhereClause.extractKeysFromColumns). But, right now you're allowed to define
a CF with columns "a" and "A" but no way to disambiguate at SELECT time which one you actually
want. So, the important part of what Sylvain is talking about here is "... unless they are
enclosed in single or double quotes," i.e., to allow you to write {{SELECT "A"}} to be explicit
about which one you want.  I don't see this breaking anything.

I don't understand this, they look to be case-sensitive to me.  Are we talking about the same

> CQL support for compound columns and wide rows
> ----------------------------------------------
>                 Key: CASSANDRA-2474
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>            Reporter: Eric Evans
>            Assignee: Sylvain Lebresne
>            Priority: Critical
>              Labels: cql
>             Fix For: 1.1
>         Attachments: 0001-Add-support-for-wide-and-composite-CFs.patch, 0002-thrift-generated-code.patch,
2474-transposed-1.PNG, 2474-transposed-raw.PNG, 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG,, raw_composite.txt, screenshot-1.jpg, screenshot-2.jpg
> For the most part, this boils down to supporting the specification of compound column
names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to
create structures from the results.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message