[
https://issues.apache.org/jira/browse/CASSANDRA-10216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14743413#comment-14743413
]
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: 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)
