cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Tunnicliffe (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10216) Remove target type from internal index metadata
Date Thu, 10 Sep 2015 18:20:46 GMT


Sam Tunnicliffe commented on CASSANDRA-10216:

[~slebresne] I've pushed a branch [here|]
for review. {{target_type}} and {{target_columns}} have been removed from {{system_schema.indexes}}
and the corresponding fields removed from {{IndexMetadata}}. The target details are now just
another option in {{index_options}}, which is reserved like the {{class}} option for custom
indexes. Parsing of the target info is down to the index implementation now, which like you
said shouldn't be too big a of a deal. Built-in indexes just use a regex for this now as the
range of targets they support is fairly trivial. 

The parsing function in the built-in indexes is reused by {{ThriftConversion}} when constructing
a {{CfDef}}, which I guess should be safe.

[~aholmber], [~adutra] 
Obviously, this requires some driver changes (and will need to be added to the CQL spec &
docs). Because I needed it for cqlsh & dtests during development, I've pushed a branch
of the python driver [here|].

Also, a tiny change to the cqlsh dtest, as we no longer automatically drop an index if the
column it targetted is dropped - [branch|]

> Remove target type from internal index metadata
> -----------------------------------------------
>                 Key: CASSANDRA-10216
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sam Tunnicliffe
>            Assignee: Sam Tunnicliffe
>              Labels: client-impacting
>             Fix For: 3.0.0 rc1
> As part of CASSANDRA-6716 & in anticipation of CASSANDRA-10124, a distinction was
introduced between secondary indexes which target a fixed set of 1 or more columns in the
base data, and those which are agnostic to the structure of the underlying rows. This distinction
is manifested in {{IndexMetadata.targetType}} and {{system_schema.indexes}}, in the {{target_type}}
column. It could be argued that this distinction complicates the codebase without providing
any tangible benefit, given that the target type is not actually used anywhere.
> It's only the impact on {{system_schema.indexes}} that makes puts this on the critical
path for 3.0, any code changes are just implementation details. 

This message was sent by Atlassian JIRA

View raw message