[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187031#comment-13187031
]
Gary Dusbabek commented on CASSANDRA-2474:
------------------------------------------
Apologies for quoting from difference sources.
bq. (Jonathan) 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.
bq. (Jake) We've run out of paint for the bikeshed. Now that the work is being
done we need to go back and re-explain the issue?
Sorry. I traded my cassandra dev hat for a user hat a year ago cannot devote
the same kind of energy towards tracking the project. Tracking tickets like
this is difficult. I wasn't suggesting abandoning wide-row support or letting
CQL stagnate though. I was objecting to a set of changes that I see as being
disruptive towards at least a subset of CQL users.
One of the strongest cases for CQL is user experience. The previously proposed
(prior to today) changes do not make CQL a better user experience.
bq. (Sylvain) So following Jake's idea, I propose to create a new cql3 package
in the code to implement the ideas of this ticket without the burden of keeping
backward compatibility, nor the fear to break previous versions.
bq. (Sylvain) This probably mean we'll want to add a new version parameter to
the thrift call or something but that's probably a good thing to have anyway.
If I understand this correctly, it sounds like a "compatability mode" where the
driver (or whatever) stipulates the mode and can go about it's business using
that level of syntax. As a driver developer and a CQL user, I think this is a
good idea.
bq. (Jonathan) But wishing for an alpha-release API to be 100% stable is a
level of fantasy...
Rubbish. CQL has been 1.0 since 0.8. That's not alpha. This may boil down to
a perception of what 1.0. means, but I think it is safe to say that it doesn't
imply alpha. 1.0, to me at least, has always implied 'ready for production'
and 'please use this now'.
bq. (Jonathan) But let's be clear: past 1.1, anyone who wants the old cql
package maintained is going to need to roll up his sleeves and pitch in...
I totally get that things need to change and am behind what Jake and Sylvain
propose. My hope was that more consideration be given to user impact before
deciding to break compatability. I think it will be important that users
perceive CQL to be stable enough to build applications with. Three backwards
incompatible versions in lockstep with three releases of Cassandra doesn't
signal that to me.
> 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
