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 16:31:46 GMT


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|]).
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:
>             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