[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13186114#comment-13186114
]
Jonathan Ellis commented on CASSANDRA-2474:
-------------------------------------------
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.
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.
What should you do if backwards compatibility is your highest priority? You
should absolutely be using the Thrift API, where we *have* guaranteed 100%
backwards compatibility. There are legitimate reasons to be a CQL early adopter
(primarily ease of driver implementation, which I assume is what drove your
decision to go that route for Node.js) but backwards compatibility is not one
of them.
Will we get to a point eventually where we can say "100% backwards
compatibility in CQL from here on out?" Absolutely. But we're just not there
yet. Fortunately, there aren't many production CQL installations yet, so, with
all due respect for your situation, we can fix mistakes and add features
without *too* much pain yet, compared to the pain from leaving them festering
(and not adding features like this one).
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.
This is a long way of saying that as a general principle, dropping blanket -1s
on CQL changes to force compatibility-by-stagnation is irresponsible at this
point.
Now, to the specifics of your objections:
bq. pre-emptive -1 on supporting [.. notation] for one more version and then
removing it
We could probably stretch this out to two releases, but as I've explained, we
shouldn't be committing to "forever". We need to be able to fix misfeatures
without paying the tax of keeping deprecated interfaces around indefinitely.
bq. The two reasons you gave are subjective
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.)
bq. How about we leave them the way they are BECAUSE USERS EXPECT IT TO BE THAT
WAY?
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 *think* you're saying that users expect things to be case-sensitive,
because CQL has never worked that way, but just in case, I'll also point out
that both SQL and the CLI treat column names case insensitive, so I'd be very
surprised if many users agree that sensitive is "expected.")
> 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
