[jira] [Commented] (CASSANDRA-10216) Remove target type from internal index metadata

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-10216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14718321#comment-14718321 ] 

Sylvain Lebresne commented on CASSANDRA-10216:
----------------------------------------------

Since this comes from an offline discussion with Sam, I'll expand on my point of view. I don't like that internal distinction we make between "column" and "row" index because every index is a row index, it gets a row (a bunch of column values) and decide to index it or not. Whether it checks a single column value to do so or multiple values, and how exactly it indexes, are implementation details of the index. Or to put it another way, every index is a column (value) index because a row is really just a bunch of column, nothing else. So I truly think this notion of "column" versus "row" is ill-defined.

To be more concrete, when we do:
{noformat}
CREATE INDEX foo ON t(c1, c2);
{noformat}
then I think {{c1, c2}} are really just options to be passed to the index implementation. Or parameters if you prefer. Now, if a custom index doesn't have a need for that option/parameter because which column values it'll look is defined in some other way (though it's {{OPTIONS}} map typically), it's fine, it just takes an empty list of parameter, but that doesn't make it a particular type of index.

Regarding the {{system_schema.indexes}} and how we handle this internally, I think I would actually even prefer to move the {{target_columns}} inside the index {{options}} map. If only because what we pass to the {{CREATE INDEX}} is not necessarily a set of columns, it can be a function (we already support some hard-coded functions for maps but we'll want to expand that for true functional index soon enough).
Currently, for map indexes, we extract the columns into {{target_columns}} and have separate had-hock options for the different functions (keys, values, keys_and_values). If instead we were to remove {{target_columns}} (and {{target_type}} obviously) and simply have a "reserved" {{target}} option in the {{options}} map, whose value would be the string in the {{CRATE INDEX}} query, then that would:
* replace the pretty had-hock "index_keys", "index_values", "index_keys_and_values". This replacement would make {{system_schema.indexes}} more user friendly since the translation between the table results and the original {{CREATE INDEX}} statement it represents would be a lot more direct.
* be future proof for functional indexes, which would be handled consistently with our pre-existing hard-coded map indexes (that are functional indexes after all).
That would leave the parsing of that {{target}} option to index implementations, but that's not a big deal and having it be completely generic might offer interesting possibility in the future.

Now, I do believe that this {{target}} option suggestion is the best way to go, but if there is strong opposition, I do think we should at least get rid of {{target_type}} for the reasons expressed above (custom indexes that don't need any particular target will just use an empty set for {{target_columns}}, which will be more consistent with the {{CREATE INDEX}} syntax suggested by [~beobal] in CASSANDRA-10124 anyway).


> 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
>             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)