[
https://issues.apache.org/jira/browse/CASSANDRA-10216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14739278#comment-14739278
]
Sam Tunnicliffe commented on CASSANDRA-10216:
---------------------------------------------
[~slebresne] I've pushed a branch
[here|https://github.com/beobal/cassandra/tree/10216-3.0] 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|https://github.com/beobal/python-driver/tree/10216].
Also, a tiny change to the cqlsh dtest, as we no longer automatically drop an
index if the column it targetted is dropped -
[branch|https://github.com/beobal/cassandra-dtest/tree/10216]
> Remove target type from internal index metadata
> -----------------------------------------------
>
> Key: CASSANDRA-10216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10216
> 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
(v6.3.4#6332)
