cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-2480) Named keys / virtual columns
Date Thu, 09 Jun 2011 22:09:58 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046849#comment-13046849
] 

Jonathan Ellis commented on CASSANDRA-2480:
-------------------------------------------

bq. if we will try to compare without check it will fail

well, yes, but that's why I just wrote that "all the key and column name comparisons should
be case insensitive" :)

bq. you will need to convert it to string before uppercase/downcase and then uppercase/downcase
key given by user and compare them. 

Right. (It may well be that we want to keep a String version of the key name in CFMD as well
for efficiency.)

bq. We can't uppercase user given key automatically.

Why not?  It originates as a string, so either (1) we can just leave it as a string or (2)
if we convert to bytebuffer we know what the encoding is so we can convert back to string.

> Named keys / virtual columns
> ----------------------------
>
>                 Key: CASSANDRA-2480
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2480
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: API, Core
>            Reporter: Eric Evans
>            Assignee: Pavel Yaskevich
>              Labels: cql
>             Fix For: 0.8.1, 1.0
>
>         Attachments: CASSANDRA-2480-v2.patch, CASSANDRA-2480.patch
>
>
> With the completion of CASSANDRA-2396, it is now possible to attach a name to keys (column
family-wide).  This could be utilized to introduce the concept of "virtual columns" in CQL.
Here's how that would work:
> Typically you would use the CQL keyword {{KEY}} to specify a row key, for example:
> {code:SQL|title=CQL 1.0}
> INSERT INTO cf (KEY, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE KEY = key1
> SELECT name1,name2 FROM cf WHERE KEY = key1
> {code}
> For CQL 1.1, that syntax would continue to work, but upon the completion of this issue
it should also be possible to assign a name to the key and treat as if it were another column.
 For example:
> {code:SQL|title=CQL 1.1}
> INSERT INTO cf (keyname, name1, name2) VALUES (key1, value1, value2)
> -- or alternately
> UPDATE cf SET name1 = value1, name2 = value2 WHERE keyname = key1
> -- Note how the keyname can now be used in the projection
> SELECT keyname, name1, name2 FROM cf WHERE keyname = key1
> -- And, there is no restriction on the order
> SELECT name1, name2, keyname FROM cf WHERE keyname = key1 AND name2 = value2
> {code}
> The semantics will be such that the existing behavior is maintained (read: when using
the {{KEY}} keyword), but if the key is named, and the name is used in a {{SELECT}}, the key's
name and value will be returned in the column results, sorted according to the comparator
(_Note: we'll need to figure out what that means with respect to differently typed keys_).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message