[
https://issues.apache.org/jira/browse/CASSANDRA-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195596#comment-13195596
]
Sylvain Lebresne commented on CASSANDRA-3782:
---------------------------------------------
I'll refer to the following comment on CASSANDRA-3761:
https://issues.apache.org/jira/browse/CASSANDRA-3761?focusedCommentId=13191984&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13191984
I fully agree my example is not particularly clear in that you can wonder why
you would do that indexing. I really only picked it to illustrate the proposed
syntax.
So in the comment above, Thorsten gives two examples of using a secondary index
(the ones we have right now) for a wide row. As he is himself admitting, it's
abusing a bit the column name, basically creating a column with a fixed name in
a wide row just for the purpose of re-using the secondary index mechanism to
find rows based on some criteria. Of course, we could decide whether we want to
disallow this on purpose, but I don't see a very good reason to do that since
it's not a lot of work, at least someone cares about it and both thrift and CQL
2.0 allows it.
> Secondary indexes support for wide rows in CQL 3.0
> --------------------------------------------------
>
> Key: CASSANDRA-3782
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3782
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Fix For: 1.1
>
>
> Currently, CQL 3.0 doesn't allow creating an index on a dynamic CF (with
> COMPACT STORAGE). The goal of this ticket is *not* to support the composite
> case however (CASSANDRA-3680 will tackle this).
> I think changes needed to support this are only in the CQL side and covert
> two area:
> * Finding a syntax for it
> * Currently, the CQL 3 code consider that a CF with any column_metadata
> defined is a non-compact cf. Basically the problem is that we currently use
> column_metadata both for defining a name for a column in the static case, and
> store indexing information. Ideally, we would separate those informations,
> i.e. we could add a new map valueAliases (ByteBuffer -> AbstractType) to
> CFMetadata (only used by static CF) and we would keep column_metadata for
> indexing purpose only. However that may be problematic for backward
> compatibility (with thrift in particular), so probably instead we can just
> add a new boolean isStaticColumnName to ColumnDefinition.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
