[ 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)