[jira] [Issue Comment Deleted] (CASSANDRA-9459) SecondaryIndex API redesign

["Andrew Hust (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-9459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Hust updated CASSANDRA-9459:
-----------------------------------
    Comment: was deleted

(was: When creating separate indexes on both the key and value of a map column the ddl for the table in cqlsh only contains the index on the value.  Both indexes are functional and queries return expected results.  When querying metadata from the python driver (3.0.0a2) both indexes are present and using the function as_cql_query produces the correct ddl.  This might just be an out of date python lib in cqlsh.

Tested on C*: {{66b0e1d7889d0858753c6e364e77d86fe278eee4}}

Can be reproduced with the following shell commands and ccm:
{code}
ccm remove 2i_test
ccm create -n 1 -v git:cassandra-3.0 -s 2i_test
ccm start

cat << EOF | ccm node1 cqlsh
CREATE KEYSPACE index_test_ks WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};
USE index_test_ks;
CREATE TABLE tbl1 (id uuid primary key, ds map<text, int>, c1 int);
INSERT INTO tbl1 (id, ds, c1) values (uuid(), {'foo': 1, 'bar': 2}, 1);
INSERT INTO tbl1 (id, ds, c1) values (uuid(), {'faz': 1, 'baz': 2}, 2);
CREATE INDEX ix_tbl1_map_values ON tbl1(ds);
CREATE INDEX ix_tbl1_map_keys ON tbl1(keys(ds));

SELECT * FROM tbl1 where ds contains 1;
SELECT * FROM tbl1 where ds contains key 'foo';

// *******
// DDL only has ix_tbl1_map_values present
// *******
DESC TABLE tbl1;

// *******
// system_schema.indexes is correct
// *******
SELECT * FROM system_schema.indexes;
EOF
ccm stop
{code}

Example output:
{code}
CREATE TABLE index_test_ks.tbl1 (
    id uuid PRIMARY KEY,
    c1 int,
    ds map<text, int>
) WITH bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99PERCENTILE';
CREATE INDEX ix_tbl1_map_values ON index_test_ks.tbl1 (ds);


 keyspace_name | table_name | index_name         | index_type | options              | target_columns | target_type
---------------+------------+--------------------+------------+----------------------+----------------+-------------
 index_test_ks |       tbl1 |   ix_tbl1_map_keys | COMPOSITES |   {'index_keys': ''} |         {'ds'} |      COLUMN
 index_test_ks |       tbl1 | ix_tbl1_map_values | COMPOSITES | {'index_values': ''} |         {'ds'} |      COLUMN
{code})

> SecondaryIndex API redesign
> ---------------------------
>
>                 Key: CASSANDRA-9459
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9459
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sam Tunnicliffe
>            Assignee: Sam Tunnicliffe
>             Fix For: 3.0 beta 1
>
>
> For some time now the index subsystem has been a pain point and in large part this is due to the way that the APIs and principal classes have grown organically over the years. It would be a good idea to conduct a wholesale review of the area and see if we can come up with something a bit more coherent.
> A few starting points:
> * There's a lot in AbstractPerColumnSecondaryIndex & its subclasses which could be pulled up into SecondaryIndexSearcher (note that to an extent, this is done in CASSANDRA-8099).
> * SecondayIndexManager is overly complex and several of its functions should be simplified/re-examined. The handling of which columns are indexed and index selection on both the read and write paths are somewhat dense and unintuitive.
> * The SecondaryIndex class hierarchy is rather convoluted and could use some serious rework.
> There are a number of outstanding tickets which we should be able to roll into this higher level one as subtasks (but I'll defer doing that until getting into the details of the redesign):
> * CASSANDRA-7771
> * CASSANDRA-8103
> * CASSANDRA-9041
> * CASSANDRA-4458
> * CASSANDRA-8505
> Whilst they're not hard dependencies, I propose that this be done on top of both CASSANDRA-8099 and CASSANDRA-6717. The former largely because the storage engine changes may facilitate a friendlier index API, but also because of the changes to SIS mentioned above. As for 6717, the changes to schema tables there will help facilitate CASSANDRA-7771.



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