[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2474:
--------------------------------------
Attachment: 2474-transposed-select-no-sparse.PNG
bq. I would say that 'sucking much less' doesn't necessarily make it 'the right
solution'.
This is more than sucking less. This is adapting exactly to the relational
philosophy that SQL is about sets of records and predicates that deal with
them, and how things are stored is an implementation detail. I don't see how
we can do better than this or something like it.
bq. Typically, you can do {{UPDATE test1 SET prop2 = 42 WHERE key = 'someKey'}}
but you cannot do the same [statement] on test2.
That's a good point, although I think the limitations are fairly easy to
explain, along with the effect on ordering.
bq. The SPARSE don't add any new possibility, it just adds a presumably better
syntax for a specific case.
Technically that is true, but that is akin to arguing that because PHP is
Turing complete it's as good as Java to write databases in. :)
Consider my timeline example. If we defined the table without SPARSE, as
{noformat}
CREATE TABLE timeline (
userid int primary key,
posted_at uuid,
column string,
value blob
) TRANSPOSED
{noformat}
The query {{SELECT * FROM timeline WHERE user_id = 'tjefferson' AND posted_at >
1770}} would give us
!2474-transposed-select-no-sparse.PNG!
I don't see how this is usable in any reasonable sense of the word. Am I
missing something?
(And no, "just model it with dense composites" is not an option for the mview
use case, where adding new columns requires rebuilding the entire CF. That's a
big win for us, and I'm not willing to give it up.)
bq. I would actually be in favor of having the first step on this being the
addition of a very simple 'raw' notation to access composites.
I'm strongly against this or any "row slicing" notation, it's a terrible fit
for anything that wants to deal with resultsets of rows sharing a common set of
columns (i.e., CQL and its drivers). Unless this actually returns rows instead
of columns which is not at all implied by the syntax. Strongly against that
too. :)
> CQL support for compound columns
> --------------------------------
>
> 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: Pavel Yaskevich
> Labels: cql
> Fix For: 1.1
>
> Attachments: 2474-transposed-1.PNG, 2474-transposed-raw.PNG,
> 2474-transposed-select-no-sparse.PNG, 2474-transposed-select.PNG,
> 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
