cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8473) Secondary index support for key-value pairs in CQL3 maps
Date Fri, 12 Dec 2014 21:52:13 GMT

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

Tyler Hobbs commented on CASSANDRA-8473:
----------------------------------------

Awesome!  Thanks for the patch.  This is quite good so far.

Here are my review comments:

* SingleColumnRelation.toReceivers():
** For lists, this error message may be confusing: {{checkTrue(receiver.type instanceof MapType,
"Column \"%s\" cannot be used as a map", receiver.name);}}.  For example, if you do {{WHERE
mylist\[0\] = 'foo'}}, you're not really trying to use it as a map.  You may want to handle
lists specially.
** The {{checkFalse()}} statement below this is starting to get confusing, I would break it
up
** Use curly braces on the "if" clause when they're used on the "else"
** I'm not sure that frozen maps are handled correctly here (e.g. {{WHERE myfrozenmap\['foo'\]
= 'bar'}}). May want to double-check that.
* SingleColumnRestriction.Contains:
** Update class-level comment (should be a javadoc) to include map entry restrictions
** entries(): no need for curly braces with a single-line for-loop
* CreateIndexStatement:
** switch on target.type could be clearer if re-organized; also, the error message about 'keys'
is slightly misleading for 'entries' indexes
* IndexTarget.TargetType.fromIndexOptions(): 
** Should this return FULL if index_values isn't present? Also, no curlies needed for single-line
clauses.
* ExtendedFilter: 
** {{else if (expr.isContains())}} will always be false (due to the {{isContains()}} check
above).
* CompositesIndex:
** No nested ternaries, please
* CompositesIndexOnCollectionKeyAndValue:
** makeIndexColumnPrefix(): need to use {{min(count - 1, cellName.size())}} for loop end (see
CASSANDRA-8053 for why)
** by extending CompositesIndexOnCollectionKey, you could eliminate about half of the methods
** isStale(): instead of building a new composite to compare with the index entry key, why
not compare the cell value with the second item in the index entry composite? This method
could also use a comment or two
* SecondaryIndexOnMapEntriesTest:
** Unusued and commented out imports
** Add a test for {{map\[element\] = null}} being invalid. (While we could support this when
filtering, we couldn't support it with a 2ary index lookup.)

Thanks again!

> Secondary index support for key-value pairs in CQL3 maps
> --------------------------------------------------------
>
>                 Key: CASSANDRA-8473
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8473
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Samuel Klock
>            Assignee: Samuel Klock
>         Attachments: cassandra-2.1-8473.txt
>
>
> CASSANDRA-4511 and CASSANDRA-6383 made substantial progress on secondary indexes on CQL3
maps, but support for a natural use case is still missing: queries to find rows with map columns
containing some key-value pair.  For example (from a comment on CASSANDRA-4511):
> {code:sql}
> SELECT * FROM main.users WHERE notify['email'] = true;
> {code}
> Cassandra should add support for this kind of index.  One option is to expose a CQL interface
like the following:
> * Creating an index:
> {code:sql}
> cqlsh:mykeyspace> CREATE TABLE mytable (key TEXT PRIMARY KEY, value MAP<TEXT, TEXT>);
> cqlsh:mykeyspace> CREATE INDEX ON mytable(ENTRIES(value));
> {code}
> * Querying the index:
> {code:sql}
> cqlsh:mykeyspace> INSERT INTO mytable (key, value) VALUES ('foo', {'a': '1', 'b':
'2', 'c': '3'});
> cqlsh:mykeyspace> INSERT INTO mytable (key, value) VALUES ('bar', {'a': '1', 'b':
'4'});
> cqlsh:mykeyspace> INSERT INTO mytable (key, value) VALUES ('baz', {'b': '4', 'c':
'3'});
> cqlsh:mykeyspace> SELECT * FROM mytable WHERE value['a'] = '1';
>  key | value
> -----+--------------------------------
>  bar |           {'a': '1', 'b': '4'}
>  foo | {'a': '1', 'b': '2', 'c': '3'}
> (2 rows)
> cqlsh:mykeyspace> SELECT * FROM mytable WHERE value['a'] = '1' AND value['b'] = '2'
ALLOW FILTERING;
>  key | value
> -----+--------------------------------
>  foo | {'a': '1', 'b': '2', 'c': '3'}
> (1 rows)
> cqlsh:mykeyspace> SELECT * FROM mytable WHERE value['b'] = '2' ALLOW FILTERING;
>  key | value                         
> -----+--------------------------------
>  foo | {'a': '1', 'b': '2', 'c': '3'}
> (1 rows)                             
> cqlsh:mykeyspace> SELECT * FROM mytable WHERE value['b'] = '4';
>  key | value
> -----+----------------------
>  bar | {'a': '1', 'b': '4'}
>  baz | {'b': '4', 'c': '3'}
> (2 rows)
> {code}
> A patch against the Cassandra-2.1 branch that implements this interface will be attached
to this issue shortly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message