[
https://issues.apache.org/jira/browse/CASSANDRA-8473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Samuel Klock updated CASSANDRA-8473:
------------------------------------
Attachment: cassandra-2.1-8473-actual-v1.txt
bq. Also, I noticed that your patch applies to trunk (despite the name). I do
feel like it would be better to target 3.0 than 2.1 for this, so I'm going to
change the fixVersion to 3.0 unless there are strong objections.
Sorry about that! Bookkeeping error on my part. I'm attaching a version of
the patch that should be based against 2.1 (as intended). I haven't yet
addressed your (very good) feedback, but I will do so in the next day or two.
The logic in both patch versions is very similar, so most of your feedback
should apply to them both. I'll update both patches to reflect your
observations.
Regarding the fixVersion: the folks in my organization would definitely vote
for a 2.1.x target if that's feasible. We have a use case for this
functionality that we're planning to deploy to production in the next few
months, and we plan to do so using a 2.1.x release. We certainly have the
option of using the 2.1 version of patch against our internal Cassandra
project, but of course we would prefer not to do so.
> 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
> Fix For: 3.0
>
> Attachments: cassandra-2.1-8473-actual-v1.txt, 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)
