[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13186380#comment-13186380
]
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.
{quote}
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.
{quote}
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.
{quote}
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.
{quote}
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 good.
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.
{quote}
Let me elaborate. We're not actually removing functionality here. The new-style
definition of
{code}
CREATE TABLE foo (
key <type1> PRIMARY KEY,
column <type2>,
value <type3>
) WITH COMPACT STORAGE
{code}
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.)
{quote}
What is the effect on users with an existing schema?
{quote}
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.
{quote}
I don't understand this, they look to be case-sensitive to me. Are we talking
about the same thing?
> CQL support for compound columns and wide rows
> ----------------------------------------------
>
> Key: CASSANDRA-2474
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
> 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, cql_tests.py, 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
