[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns and wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-2474: Component/s: (was: Materialized Views) > 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: CQL >Reporter: Eric Evans >Priority: Critical > Labels: cql > 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, ASF.LICENSE.NOT.GRANTED--screenshot-1.jpg, > ASF.LICENSE.NOT.GRANTED--screenshot-2.jpg, cql_tests.py, raw_composite.txt > > > 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 was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns and wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-2474: Component/s: Materialized Views > 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: CQL, Materialized Views >Reporter: Eric Evans >Priority: Critical > Labels: cql > 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, ASF.LICENSE.NOT.GRANTED--screenshot-1.jpg, > ASF.LICENSE.NOT.GRANTED--screenshot-2.jpg, cql_tests.py, raw_composite.txt > > > 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 was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns and wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-2474: -- Reviewer: urandom 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
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns and wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2474: Attachment: 3742.patch Attaching patch implementing the idea described above (includes a unit test). Note that when this option is used the patch does not trim the result post-reconciliation of the result of the different replicas. The reason being that this can be done more simply and more efficiently on the CQL side (i.e, after the creation of the CqlResult object). 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
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns and wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2474: Attachment: 0002-thrift-generated-code.patch 0001-Add-support-for-wide-and-composite-CFs.patch Attaching initial patch. It's not complete but close I believe and presentable enough that whoever wants to review can start looking at it. First, the things that are not working/not ready: * LIMIT: as said previously, I'll have to do CASSANDRA-3742 before. * The '..' notation is broken. The syntax still supports it but it's ignored right now. I'll probably add back the support (keeping the resultset has previously for backward compatibility). It would be worth running a number of existing CQL tests against this to see if there is other broken backward compatibility problem but I haven't yet done it. On the other side, the tests I previously attached (cql_test.py) are all passing with this patch. There is also a few simple improvements that could be done that I've not done yet by lack of time: * There is no query that translate to a query-by-name on 'compact' CF (dynamic or composite dense ones). Allowing it would mean allowing IN relation for the last part of multi-component PRIMARY KEY. * As I was hinting in a previous comment, select, update and delete now have a post-parsing validation/preprocessing phase that is not totally trivial. He would be a little more efficient (and not hard) to make that preprocessing parts of the prepared statements preparation. 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
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns and wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2474: Attachment: cql_tests.py 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: 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
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns and wide rows
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2474: -- Summary: CQL support for compound columns and wide rows (was: CQL support for compound columns) 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 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
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-2474:
Attachment: raw_composite.txt
bq. True, but none of the other proposals even come close to being as friendly
as this one for typical cases
Playing devils advocate I would say that 'sucking much less' doesn't
necessarily make it 'the right solution'.
Now, don't get me wrong, I like the TRANSPOSED idea for composite. But I think
you made 2 proposals:
# a reasonably generic way to access CF with composite comparator in a CQL-ish
way: the TRANSPOSED part.
# an attempt at some special handling for the case of composites where the last
component takes only a know number of values: the SPARSE thing.
I do like the first part. Though I'd like to mention some remarks on the
following comment:
bq. We're using TRANSPOSED AS similarly to how databases have used storage
hints like CLUSTERED. It doesn't affect the relational model of the data, but
it gives you different performance characteristics
While I understand what you mean, I don't think it's completely true. Because
in the transposed case, the order of definition matters, which has a
consequence on what you can do, both in terms of writes and reads.
Consider the two definitions:
{noformat}
CREATE TABLE test1 (
key text primary key,
prop1 int,
prop2 int,
prop3 int
)
{noformat}
and
{noformat}
CREATE TABLE test2 (
key int primary key,
prop1 int,
prop2 int,
prop3 int
) TRANSPOSED AS (prop1, prop2)
{noformat}
Those two definitions don't only differ from a performance standpoint.
Typically, you can do
{noformat}
UPDATE test1 SET prop2 = 42 WHERE key = 'someKey';
{noformat}
but you cannot do the same query on test2. Btw, for test2, you don't
necessarily have to specify prop2 for every row, but you need at least prop1
and prop3 each time. My point being that you do have to understand a bit what
is going on underneath to understand the limitation we will have to put on this.
You also have the similar thing for gets: you can do
{noformat}
SELECT prop2 FROM test1 WHERE key = 'someKey';
{noformat}
but this make no sense with test2 (or rather there is no way we can do this
efficiently, i.e, without reading the row fully).
That being said, I'll reiter that I'm reasonably convinced by this
transposition notion, even though I'll probably prefer to write it as
{noformat}
CREATE TRANSPOSED TABLE test2 (
key int primary key,
prop1 int,
prop2 int,
prop3 int
)
{noformat}
as was suggested in some comments above.
On the SPARSE thing, I am much less convinced that this is the right solution.
I think that having at the same 'level' variables that are just names to
identify values in the resultset (posted_at) and literals (posted_by) is
confusing (and ugly). (As a side note, I don't understand the choice of the
SPARSE word).
Overall, I'm afraid we'll end up doing some bad choice by trying to do too much
at once. The first problem we have is that CQL, that we'd like to push as the
de-facto way to access Cassandra, doesn't allow access to composite columns at
all. It seems to me that the transposed alone fixes that (again, except for the
dynamic composite type). The SPARSE don't add any new possibility, it just adds
a presumably better syntax for a specific case. I would be in favor of moving
this to a second step (which would be less urgent and would allow refocusing
the discussion on that very specific optimisation).
Lastly, and for the record, 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. Something that could look like the example in the attached file
'raw_composite.txt' (put separatly because this comment is way too long
already). The advantages being that: it's super simple to do, it'll be natural
for users coming from thrift and it'll have not specific limitation (in
particular it'll handle dynamic composites). Then, a second step would be to
add more limited but more user-friendly notation to deal with specific cases
(like the transposed and the sparse thing).
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.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
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns
[
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
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns
[
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-1.PNG
2474-transposed-raw.PNG
The crucial part of this latest proposal is that it really highlights that
transposition really is just an implementation detail from the relational
perspective. So, to flesh that out:
{code}
INSERT INTO timeline (user_id, posted_at, posted_by, body)
VALUES ('tjefferson', '1818', 'jadams', 'Revolution was effected before the war
commenced');
INSERT INTO timeline (user_id, posted_at, posted_by, body)
VALUES ('tjefferson', '1763', 'jadams', 'Democracy will soon degenerate into an
anarchy');
INSERT INTO timeline (user_id, posted_at, posted_by, body)
VALUES ('tjefferson', '1790', 'gwashington', 'To be prepared for war is one of
the most effectual means of preserving peace');
INSERT INTO timeline (user_id, posted_at, posted_by, body)
VALUES ('bfranklin', '1781', 'tjefferson', 'Every government degenerates when
trusted to the rulers of the people alone');
{code}
... corresponding to the data in !2474-transposed-1.PNG!, which in raw form
looks like !2474-transposed-raw.PNG!
Does that make sense? We're using TRANSPOSED AS similarly to how databases
have used storage hints like CLUSTERED. It doesn't affect the relational model
of the data, but it gives you different performance characteristics. (The
analogy is particularly apt in that both CLUSTERED and TRANSPOSED AS affect
ordering of results.)
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,
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
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns
[
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.PNG
So, you could do queries like
{code}
SELECT * FROM timeline WHERE user_id = 'tjefferson' AND posted_ad 1770;
{code}
Which would give the resultset shown in !2474-transposed-select.PNG!
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.PNG, 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
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2474: Fix Version/s: (was: 1.0.7) 1.1 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: 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
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2474: -- Issue Type: New Feature (was: Sub-task) Parent: (was: CASSANDRA-2472) 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.0.1 Attachments: 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2474: -- Fix Version/s: (was: 1.0) 1.1 CQL support for compound columns Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Assignee: Pavel Yaskevich Labels: cql Fix For: 1.1 Attachments: 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2474: -- Attachment: screenshot-1.jpg CQL support for compound columns Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Assignee: Pavel Yaskevich Labels: cql Fix For: 1.0 Attachments: screenshot-1.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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2474: -- Attachment: screenshot-2.jpg CQL support for compound columns Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Assignee: Pavel Yaskevich Labels: cql Fix For: 1.0 Attachments: 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2474: -- Labels: cql (was: ) CQL support for compound columns Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Labels: cql Fix For: 1.0 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Evans updated CASSANDRA-2474: -- Description: 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. CQL support for compound columns Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Fix For: 1.0 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
