You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2012/06/11 14:23:42 UTC
[jira] [Created] (CASSANDRA-4329) CQL3: Always use composite types
by default
Sylvain Lebresne created CASSANDRA-4329:
-------------------------------------------
Summary: 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
Fix For: 1.2
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
[jira] [Resolved] (CASSANDRA-4329) CQL3: Always use composite types
by default
Posted by "Pavel Yaskevich (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Yaskevich resolved CASSANDRA-4329.
----------------------------------------
Resolution: Fixed
Rebased and committed.
> 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
[jira] [Reopened] (CASSANDRA-4329) CQL3: Always use composite types
by default
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brandon Williams reopened CASSANDRA-4329:
-----------------------------------------
Looks like this broke token selection:
{noformat}
INFO [main] 2012-07-02 14:08:36,773 StorageService.java (line 680) JOINING: schema complete, ready to bootstrap
INFO [main] 2012-07-02 14:08:36,773 StorageService.java (line 680) JOINING: getting bootstrap token
INFO [main] 2012-07-02 14:08:36,780 ColumnFamilyStore.java (line 630) Enqueuing flush of Memtable-local@276008395(46/46 serialized/live bytes, 1 ops)
INFO [FlushWriter:1] 2012-07-02 14:08:36,780 Memtable.java (line 264) Writing Memtable-local@276008395(46/46 serialized/live bytes, 1 ops)
INFO [FlushWriter:1] 2012-07-02 14:08:36,803 Memtable.java (line 305) Completed flushing /tmp/dtest-RHf5M9/test/node2/data/system/local/system-local-ia-2-Data.db (73 bytes) for commitlog position ReplayPosition(segmentId=941302507181214, position=2126)
ERROR [main] 2012-07-02 14:08:36,809 AbstractCassandraDaemon.java (line 369) Exception encountered during startup
java.lang.RuntimeException: UnavailableException()
at org.apache.cassandra.cql3.QueryProcessor.processInternal(QueryProcessor.java:135)
at org.apache.cassandra.db.SystemTable.getLocalHostId(SystemTable.java:371)
at org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:692)
at org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:559)
at org.apache.cassandra.service.StorageService.initServer(StorageService.java:449)
at org.apache.cassandra.service.StorageService.initServer(StorageService.java:341)
at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:230)
at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:352)
at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:105)
Caused by: UnavailableException()
at org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:600)
at org.apache.cassandra.cql3.statements.SelectStatement.getSlice(SelectStatement.java:225)
at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:132)
at org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:107)
at org.apache.cassandra.cql3.QueryProcessor.processInternal(QueryProcessor.java:128)
... 8 more
{noformat}
> 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
[jira] [Commented] (CASSANDRA-4329) CQL3: Always use composite
types by default
Posted by "Pavel Yaskevich (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406435#comment-13406435 ]
Pavel Yaskevich commented on CASSANDRA-4329:
--------------------------------------------
+1 with nit - instead of "system" in systemTableQuery(...) would be better to use Table.SYSTEM_TABLE
> 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, 4329_fix.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
[jira] [Updated] (CASSANDRA-4329) CQL3: Always use composite types
by default
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (CASSANDRA-4329) CQL3: Always use composite
types by default
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406451#comment-13406451 ]
Sylvain Lebresne commented on CASSANDRA-4329:
---------------------------------------------
Committed (with nit fixed). Thanks.
> 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, 4329_fix.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
[jira] [Updated] (CASSANDRA-4329) CQL3: Always use composite types
by default
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-4329:
----------------------------------------
Attachment: 4329_fix.txt
Fix attached.
> 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, 4329_fix.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
[jira] [Updated] (CASSANDRA-4329) CQL3: Always use composite types
by default
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-4329:
--------------------------------------
Reviewer: xedin
> 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
[jira] [Resolved] (CASSANDRA-4329) CQL3: Always use composite types
by default
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne resolved CASSANDRA-4329.
-----------------------------------------
Resolution: Fixed
> 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, 4329_fix.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