[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188009#comment-13188009
]
Eric Evans commented on CASSANDRA-2474:
---------------------------------------
bq. But wishing for an alpha-release API to be 100% stable is a level of
fantasy that requires either much more optimism or a much larger ego to think
that you got it THAT right on your first try without ever building anything
substantial on it first, than I'm capable of generating. And we really are
talking alpha here; beta implies feature completness, or close to it.
Getting back to expectations, where was the expectation set that CQL was
alpha-release? I know I'm not the only one who missed that memo. Granted,
it's not feature-complete, but what is? Cassandra isn't feature-complete
either (or we wouldn't still be adding features).
bq. The users I've talked see clearly that although the ultimate goal does
include stability, an incomplete API is simply not ready to deliver on that.
Which is why you see the overwhelming majority of development still done on
"classic" clients like Hector and pycassa. (And which is why I'm pushing hard
to make CQL3/1.1 feature complete. I do want CQL to succeed, but I'm realistic
about where it stands today.)
Are you saying that after CQL3/1.1, that people can expect some level of
stability? I would of course love to see a "Yes", but pretending that the need
to add or make changes won't continue, and the arguments about backward
compatibility being Hard won't continue to be relevant, require much more
optimism than I'm capable of generating.
And to be clear, when I talk about setting expectations for stability, I don't
mean "No Changes, Ever". Like I said, I understand there is a balance to
strike. But, other than assuming breakage and being pleasantly surprised if
you dodge a bullet, what can our users expect today?
bq. Jake and Sylvain's proposal sounds like the only way we're going to be able
to deliver the remaining features we need while still maintaining a
compatibility escape hatch for applications built on early CQL version. 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, because the rest of us have
plenty of things to spend our time on that are more valuable to the community
as a whole.
I think this an excellent idea, especially if we're very clear that CQL3 is
volatile. When the time comes that we're willing to commit to something, we
should be clear about that too. Bonus points if we can make a 2->3 transition
reasonable, or at least reasonably documented.
And, even if the number of CQL <= 2.0 users is small enough to be considered
acceptable collateral damage, an orderly transition like this will go a long
way toward showing everyone that we're trying not to burn them.
> 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
