[
https://issues.apache.org/jira/browse/CASSANDRA-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-5125:
----------------------------------------
Attachment: 0004-Handle-partition-key-indexing.patch
0003-Handle-new-type-of-IndexExpression.patch
0002-Generalize-CompositeIndex-for-all-column-type.patch
0001-Refactor-aliases-into-column_metadata.patch
Attaching patches for that (also pushed to
https://github.com/pcmanus/cassandra/commits/5125).
The first part of this ticket is about how we store the information that a
clustering key column is indexed. Turns out that for "regular" columns we use
ColumnDefinition and the indexing code also assumes that, so the probably best
and simplest approach is to reuse ColumnDefinition for that too. But then it's
easier to always store all primary key columns as ColumnDefinition, pretty much
obsoleting the old key_aliases and column_aliases. There is a few related
details worth noticing:
# while this obsolete the aliases, those are not removed of the schema by the
patch for compatibility sake. Truth is, I'm not sure there is a way to remove a
field from the schema without breaking rolling upgrades at this point.
# after this patch, CFDefinition becomes much less useful as CFMetadata +
ColumnDefinition holds pretty much the same information in pretty much the same
form. So we could slightly simplify things by removing CFDefinition. However,
this is left to later (this won't be a 3 lines patch).
After that, the patch adds a new type of composite indexes to handle indexing
clustering keys (which share most code with the existing regular composite
index) and update CQL3 to allow adding and querying the new indexes (in
particular, it is slighty tricky in SelectStatment to recognize when a
clustering key is restricted if 2ndary indexes should be used or not).
The last patch adds support for indexing components of the partition key (we
don't allow indexing the first component of the partition key as it makes no
sense (it's already primary indexed), but if the partition key is composite,
secondary indexing the 2+ parts can be useful).
Lastly, I'll note that the patches only add theses news indexes for non compact
tables. We should generalize to compact tables too, but that would require a
bit of generalization that I'd rather add in a second phase.
> Support indexes on composite column components
> ----------------------------------------------
>
> Key: CASSANDRA-5125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5125
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Sylvain Lebresne
> Fix For: 2.0
>
> Attachments: 0001-Refactor-aliases-into-column_metadata.patch,
> 0002-Generalize-CompositeIndex-for-all-column-type.patch,
> 0003-Handle-new-type-of-IndexExpression.patch,
> 0004-Handle-partition-key-indexing.patch
>
>
> Given
> {code}
> CREATE TABLE foo (
> a int,
> b int,
> c int,
> PRIMARY KEY (a, b)
> );
> {code}
> We should support {{CREATE INDEX ON foo(b)}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
