[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13186555#comment-13186555
]
Sylvain Lebresne commented on CASSANDRA-2474:
---------------------------------------------
bq. 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.
The problem with the '..' notation is that it works very differently from the
new proposed way to handle wide rows. In particular, maintaining it deprecated
forever means maintaining the 'SELECT FIRST', the 'SELECT REVERSED' notations
too, as well as the otherwise useless CREATE notations 'WITH comparator =
<comparator>' and 'WITH default_validator = <comparator>'. It also means
keeping forever the otherwise useless name_types and default_validator fields
of the CqlResult. And all of this will require a fair amount of specific code
since those work rather differently from their preferred replacement. I do
think it makes the balance leaning clearly over 'not maintaining deprecated
features forever' for this one.
{quote}
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.
{quote}
While I did suggested removing '..' from 1.1 in a previous comment, I
apologize, let me take that back. I was more describing the current state of
the patch in my previous comment and laying out a number of point for
discussion. But as said in a follow up comment, I'm good just deprecating '..'
and keeping it a little bit longer to make transition easier (and thus only
creating a real language break for 1.2). But keeping both '..' and the
proposition of this ticket forever is not a very viable option imho.
bq. What is the effect on users with an existing schema?
For their static CF, if they have a few columns that are not declared in the
schema, they may have to do a bunch of ALTER CF to add them. For dynamic CFs,
they'd also need to do a ALTER CF to basically declare a schema like the one
descibe a the beginning of that comment (current patch don't allow that yet,
but it's on the todo list and not a hard one to add).
bq. I don't understand this, they look to be case-sensitive to me. Are we
talking about the same thing?
If I'm not mistaken, currently the PRIMARY KEY (i.e the key_alias) is
case-sensitive and the other columns are case-insensitive. It is this
difference I'm proposing to solve basically. And this patch introduces more
aliases (column_aliases and value_alias to take the patch naming), so keeping
the difference would be more confusing I believe. So the proposal is to treat
every name declared in a CREATE TABLE the same way, whether they are part of
the PRIMARY KEY or not, and whether the CF uses COMPACT STORAGE or not. Note
that we could use case-sensitivity by default for everything. I'd be good with
that if we think it's better. But it seems to me that re-using the SQL idea to
have case-insensitivity by default with a mean to force case-sensitivity has a
user friendliness to it.
> 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
