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 Mon, 14 Sep 2015 11:57:45 GMT


Sam Tunnicliffe commented on CASSANDRA-10216:

bq. My main remark is that for the new {{target}} option, I'd prefer keeping it as close to
the {{CREATE INDEX}} definition as possible. So if it's not a collection index, I'd prefer
the "target" to just be the column name instead of defaulting to {{"values(name)"}}. My main
reasoning is that it gives an ever simpler match between the schema table and the corresponding
statement. But it also feels somewhat cleaner more future-proof to me (and "values" is plural,
which sounds weird for a non-collection column). And updating the regexp to match that doesn't
seem too hard.

Fair enough, though FTR it seemed cleaner & possibly more future-proof to be explicit
about the target type in all cases, rather than having a special case for non-collection columns.
Leaving aside the alignment with CQL this is also what happens in the code, a statement like
{{CREATE INDEX ON ks.t1(col)}} produces an {{IndexTarget}} with type {{VALUES}}. Also, the
plurality of "values" doesn't seem particularly weird on a non-collection column to me, the
index is on the values of that column, of which there is only 1 per-row but still many per-index.

I don't feel particularly strongly about it though, so I'll happily change it. Just before
I do though, you only mentioned non-collection columns. How do you want to handle indexes
on collection values? Do you want to make the value of the {{target}} string match the CQL
in those cases too, by omitting the {{values}} for indexes on lists, sets & map values?

> 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