[
https://issues.apache.org/jira/browse/CASSANDRA-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13047337#comment-13047337
]
Pavel Yaskevich commented on CASSANDRA-2480:
--------------------------------------------
But we uppercase the string from input right before we convert it into buffer
in the AM constructor, so all we do is compare that buffer with uppercased
CFMD.getKeyName and with DEFAULT_KEY_NAME.
> 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: 2480-v4-wip.txt, CASSANDRA-2480-v2.patch,
> CASSANDRA-2480-v3.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
