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