[ 
https://issues.apache.org/jira/browse/CASSANDRA-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylvain Lebresne updated CASSANDRA-4329:
----------------------------------------

    Attachment: 4329.txt

Attaching patch for this. With that, non-compact CF always use composite 
underneath. COMPACT STORAGE can be used to get back the non-composite "static" 
CF.

One details is the system tables. Instead of using COMPACT STORAGE everything, 
I've left a "new" composite CF for the local and peers CF since they are new 
for 1.2 (and that way we will able to use collections if need be). Make me 
realize that sadely the system.keyspaces CF is not a composite one, which will 
be make it harder to use sets for replication_options (i.e. we may have to 
migrate the sstables).

Anyway, another thing is that since we don't yet support indexes on composites, 
there is is no index support unless COMPACT STORAGE is used.

                
> CQL3: Always use composite types by default 
> --------------------------------------------
>
>                 Key: CASSANDRA-4329
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4329
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>              Labels: cql3
>             Fix For: 1.2
>
>         Attachments: 4329.txt
>
>
> Currently, when defining a table with a single (non-composite) PRIMARY KEY, 
> we don't use a CompositeType in the underlying comparator. This is however a 
> problem for CASSANDRA-3647 as this means those tables cannot use collections. 
>  So this ticket suggests to change that default behavior, and to always use 
> (by default at least, see below) a composite comparator underneath. I'll note 
> that doing so will mean an overhead of 3 bytes per column for non-composite 
> columns, but I believe getting collection is well worth it.
> Of course the suggestion above apply to the default behavior and this ticket 
> would also add an option to table creation to get back to the current 
> behavior of not using a composite comparator (if ony for backward 
> compatibility sake).  And I believe that we can actually reuse 'COMPACT 
> STORAGE' for that.

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

        

Reply via email to