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/10/17 09:58:03 UTC
[jira] [Created] (CASSANDRA-4822) CQL3: Allow renaming PK columns
to ease upgrade from thrift
Sylvain Lebresne created CASSANDRA-4822:
-------------------------------------------
Summary: CQL3: Allow renaming PK columns to ease upgrade from thrift
Key: CASSANDRA-4822
URL: https://issues.apache.org/jira/browse/CASSANDRA-4822
Project: Cassandra
Issue Type: Bug
Components: API
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Say you have a clicks CF in thrift storing for each user a timeline of which links it clicked on. It may have a definition like:
{noformat}
create column family clicks with key_validation_class = UUIDType and comparator = TimeUUIDType and default_validation_class = UTF8Type
{noformat}
In CQL3, you can access that thrift created CF as if it had been defined by:
{noformat}
CREATE TABLE clicks (
key uuid,
column timeuuid,
value text,
PRIMARY KEY (key, column)
) WITH COMPACT STORAGE
{noformat}
In other words, CQL3 will pick default names for the key_alias, column_aliases and value_alias metadata. It's ok but it would be more user friendly to use if the user could rename those to something better. Today, the only solution would be to remove the schema and re-create the table in CQL3. We can make that simpler by adding support for:
{noformat}
ALTER TABLE clicks RENAME key to user_id;
ALTER TABLE clicks RENAME column to insertion_time;
ALTER TABLE clicks RENAME value to url_clicked;
{noformat}
Of course such rename statement won't be applicable to all columns. Namely, we can only allow renaming PK columns and in some compact storage cases the value. But that's probably still worth adding.
--
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
[jira] [Updated] (CASSANDRA-4822) CQL3: Allow renaming PK columns
to ease upgrade from thrift
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-4822:
----------------------------------------
Attachment: 4822.txt
> CQL3: Allow renaming PK columns to ease upgrade from thrift
> -----------------------------------------------------------
>
> Key: CASSANDRA-4822
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4822
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Attachments: 4822.txt
>
>
> Say you have a clicks CF in thrift storing for each user a timeline of which links it clicked on. It may have a definition like:
> {noformat}
> create column family clicks with key_validation_class = UUIDType and comparator = TimeUUIDType and default_validation_class = UTF8Type
> {noformat}
> In CQL3, you can access that thrift created CF as if it had been defined by:
> {noformat}
> CREATE TABLE clicks (
> key uuid,
> column timeuuid,
> value text,
> PRIMARY KEY (key, column)
> ) WITH COMPACT STORAGE
> {noformat}
> In other words, CQL3 will pick default names for the key_alias, column_aliases and value_alias metadata. It's ok but it would be more user friendly to use if the user could rename those to something better. Today, the only solution would be to remove the schema and re-create the table in CQL3. We can make that simpler by adding support for:
> {noformat}
> ALTER TABLE clicks RENAME key to user_id;
> ALTER TABLE clicks RENAME column to insertion_time;
> ALTER TABLE clicks RENAME value to url_clicked;
> {noformat}
> Of course such rename statement won't be applicable to all columns. Namely, we can only allow renaming PK columns and in some compact storage cases the value. But that's probably still worth adding.
--
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
[jira] [Updated] (CASSANDRA-4822) CQL3: Allow renaming PK columns
to ease upgrade from thrift
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-4822:
----------------------------------------
Attachment: 4822-2.txt
Attaching v2 of the patch. It addresses the remarks above but now that I've been able to test it, it also includes a few new stuffs. Basically we weren't very accurate in our detection of whether the table was compact or not. Let recall that we don't "store" if a table is compact or not, we infer that from the comparator and how many column aliases exist. We probably should have store something to distinguish cql3 tables from other ones from day one, but unless we want to break all existing CQL3 table now we have to stick to our little detection dance.
Anyway, I've updated said detection code (in CFDefinition) to be more precise. However, there is still a small catch if we allow users to provide column aliases, which is that if a thrift user with a composite type declare all but the last column alias, we will interpret the table as non-compact but that's not correct. I don't know how to fix that, but to make sure this have little change to happen in practice, I've modified the rename to allow renaming multiple columns in the same ALTER statement. If User upgrading from thrift alter all the columns at once, they'll always be fine.
> CQL3: Allow renaming PK columns to ease upgrade from thrift
> -----------------------------------------------------------
>
> Key: CASSANDRA-4822
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4822
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 1.2.0 beta 2
>
> Attachments: 4822-2.txt, 4822.txt
>
>
> Say you have a clicks CF in thrift storing for each user a timeline of which links it clicked on. It may have a definition like:
> {noformat}
> create column family clicks with key_validation_class = UUIDType and comparator = TimeUUIDType and default_validation_class = UTF8Type
> {noformat}
> In CQL3, you can access that thrift created CF as if it had been defined by:
> {noformat}
> CREATE TABLE clicks (
> key uuid,
> column timeuuid,
> value text,
> PRIMARY KEY (key, column)
> ) WITH COMPACT STORAGE
> {noformat}
> In other words, CQL3 will pick default names for the key_alias, column_aliases and value_alias metadata. It's ok but it would be more user friendly to use if the user could rename those to something better. Today, the only solution would be to remove the schema and re-create the table in CQL3. We can make that simpler by adding support for:
> {noformat}
> ALTER TABLE clicks RENAME key to user_id;
> ALTER TABLE clicks RENAME column to insertion_time;
> ALTER TABLE clicks RENAME value to url_clicked;
> {noformat}
> Of course such rename statement won't be applicable to all columns. Namely, we can only allow renaming PK columns and in some compact storage cases the value. But that's probably still worth adding.
--
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
[jira] [Commented] (CASSANDRA-4822) CQL3: Allow renaming PK columns
to ease upgrade from thrift
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484205#comment-13484205 ]
Jonathan Ellis commented on CASSANDRA-4822:
-------------------------------------------
+1
> CQL3: Allow renaming PK columns to ease upgrade from thrift
> -----------------------------------------------------------
>
> Key: CASSANDRA-4822
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4822
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 1.2.0 beta 2
>
> Attachments: 4822-2.txt, 4822.txt
>
>
> Say you have a clicks CF in thrift storing for each user a timeline of which links it clicked on. It may have a definition like:
> {noformat}
> create column family clicks with key_validation_class = UUIDType and comparator = TimeUUIDType and default_validation_class = UTF8Type
> {noformat}
> In CQL3, you can access that thrift created CF as if it had been defined by:
> {noformat}
> CREATE TABLE clicks (
> key uuid,
> column timeuuid,
> value text,
> PRIMARY KEY (key, column)
> ) WITH COMPACT STORAGE
> {noformat}
> In other words, CQL3 will pick default names for the key_alias, column_aliases and value_alias metadata. It's ok but it would be more user friendly to use if the user could rename those to something better. Today, the only solution would be to remove the schema and re-create the table in CQL3. We can make that simpler by adding support for:
> {noformat}
> ALTER TABLE clicks RENAME key to user_id;
> ALTER TABLE clicks RENAME column to insertion_time;
> ALTER TABLE clicks RENAME value to url_clicked;
> {noformat}
> Of course such rename statement won't be applicable to all columns. Namely, we can only allow renaming PK columns and in some compact storage cases the value. But that's probably still worth adding.
--
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
[jira] [Commented] (CASSANDRA-4822) CQL3: Allow renaming PK columns
to ease upgrade from thrift
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483543#comment-13483543 ]
Jonathan Ellis commented on CASSANDRA-4822:
-------------------------------------------
I think this is backwards:
+ newList.add(i < l.size() ? null : l.get(i));
Nits: would prefer {{l}} to be given a more meaningful name, like {{oldNames}}. Comments for the aliases lists that they can be null-padded would be nice.
> CQL3: Allow renaming PK columns to ease upgrade from thrift
> -----------------------------------------------------------
>
> Key: CASSANDRA-4822
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4822
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 1.2.0 beta 2
>
> Attachments: 4822.txt
>
>
> Say you have a clicks CF in thrift storing for each user a timeline of which links it clicked on. It may have a definition like:
> {noformat}
> create column family clicks with key_validation_class = UUIDType and comparator = TimeUUIDType and default_validation_class = UTF8Type
> {noformat}
> In CQL3, you can access that thrift created CF as if it had been defined by:
> {noformat}
> CREATE TABLE clicks (
> key uuid,
> column timeuuid,
> value text,
> PRIMARY KEY (key, column)
> ) WITH COMPACT STORAGE
> {noformat}
> In other words, CQL3 will pick default names for the key_alias, column_aliases and value_alias metadata. It's ok but it would be more user friendly to use if the user could rename those to something better. Today, the only solution would be to remove the schema and re-create the table in CQL3. We can make that simpler by adding support for:
> {noformat}
> ALTER TABLE clicks RENAME key to user_id;
> ALTER TABLE clicks RENAME column to insertion_time;
> ALTER TABLE clicks RENAME value to url_clicked;
> {noformat}
> Of course such rename statement won't be applicable to all columns. Namely, we can only allow renaming PK columns and in some compact storage cases the value. But that's probably still worth adding.
--
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