[
https://issues.apache.org/jira/browse/CASSANDRA-10216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14743792#comment-14743792
]
Sam Tunnicliffe commented on CASSANDRA-10216:
---------------------------------------------
tl;dr the {{target}} stuff is changed in {{74a234d}}, (there's also a further
update to the python driver
[here|https://github.com/beobal/python-driver/commit/3e507497386f689440ebc0202b5cd95a11597dad]).
The other nits are addressed in {{cb8d43c}}.
bq.Hence why I want to match the user statement.
I totally get that, I was just thinking about the fact that the syntax itself
is somewhat inconsistent. The reason for that is completely understandable, I
was just wary of blindly reproducing it in the metadata. Also, I wasn't really
putting any weight on the current implementation of {{IndexTarget}}, just using
it to make the point that the specific syntax for 'regular' indexes is missing
some information which we have to infer. Anyway, I don't mean to labour the
point, I'm cool with going with your approach b/c of being able to recreate the
index without having to parse {{target}}.
bq.Well, since you mention it, I would have a slight preference for actually
using another "type" for that (REGULAR, NONE, SIMPLE, whatever).
wfm, I've added {{IndexTarget.Type.SIMPLE}}
bq.The fact that "values" is the default for collection is an historical
accident...but my preference would be to add support for CREATE INDEX ON
t(values(myCollection))
Sure, I'm aware that that's the history of the thing. Adding an explicit
version to the syntax is my preference too.
> 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)
