[jira] [Commented] (CASSANDRA-5702) ALTER RENAME is broken in trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13700069#comment-13700069
]
Sylvain Lebresne commented on CASSANDRA-5702:
-
Had forgot a toUppercase() call when checking the CQL2 key alias. I've
committed the trivial fix as b7e49b3.
> ALTER RENAME is broken in trunk
> ---
>
> Key: CASSANDRA-5702
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5702
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 2.0 beta 1
>
> Attachments: 5702.txt
>
>
> CASSANDRA-5125 has broken {{ALTER RENAME}} when the column is a default alias
> (for thrift column families where the PK columns haven't been renamed yet).
> The problem is basically that while we assign default aliases to PK columns
> when they don't have one, we currently "fake" those default aliases and do
> not persist them. Concretely, CFDefinition is aware of them, but CFMetaData
> is not, which break renaming post CASSANDRA-5125.
> We could fix rename punctually, but there is another related problem: for the
> same reason, if you try to create an index on a column that is a non-renamed
> default alias, this doesn't work with the arguably confusing message "No
> column definition found for column X". Here again, we could fix it
> punctually, but it starts to sound like we need a more general fix.
> So I suggest stopping to "fake" those default aliases, but instead to just
> create "real" aliases (that are known of CFMetaData and persisted in the
> schema) when there is none. After all, from a user point of view, why should
> a default column name be any special. And on top of fixing the issues above,
> this also:
> # fix CASSANDRA-5489 in a somewhat simpler way
> # makes it easier for clients reading the schema CFs. They won't to infer the
> default aliases anymore.
> The only theoretical downside is that we lose the information that a given
> CQL3 column name is one assigned by default versus one set up by the user,
> but given the user can rename those column names anyway, not sure this
> matters in any way.
--
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-5702) ALTER RENAME is broken in trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13694099#comment-13694099
]
Aleksey Yeschenko commented on CASSANDRA-5702:
--
+1
> ALTER RENAME is broken in trunk
> ---
>
> Key: CASSANDRA-5702
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5702
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 2.0 beta 1
>
> Attachments: 5702.txt
>
>
> CASSANDRA-5125 has broken {{ALTER RENAME}} when the column is a default alias
> (for thrift column families where the PK columns haven't been renamed yet).
> The problem is basically that while we assign default aliases to PK columns
> when they don't have one, we currently "fake" those default aliases and do
> not persist them. Concretely, CFDefinition is aware of them, but CFMetaData
> is not, which break renaming post CASSANDRA-5125.
> We could fix rename punctually, but there is another related problem: for the
> same reason, if you try to create an index on a column that is a non-renamed
> default alias, this doesn't work with the arguably confusing message "No
> column definition found for column X". Here again, we could fix it
> punctually, but it starts to sound like we need a more general fix.
> So I suggest stopping to "fake" those default aliases, but instead to just
> create "real" aliases (that are known of CFMetaData and persisted in the
> schema) when there is none. After all, from a user point of view, why should
> a default column name be any special. And on top of fixing the issues above,
> this also:
> # fix CASSANDRA-5489 in a somewhat simpler way
> # makes it easier for clients reading the schema CFs. They won't to infer the
> default aliases anymore.
> The only theoretical downside is that we lose the information that a given
> CQL3 column name is one assigned by default versus one set up by the user,
> but given the user can rename those column names anyway, not sure this
> matters in any way.
--
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-5702) ALTER RENAME is broken in trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13693902#comment-13693902
]
Aleksey Yeschenko commented on CASSANDRA-5702:
--
Thought about this as well (in the context of CASSANDRA-5489) and came to the
same conclusion.
> ALTER RENAME is broken in trunk
> ---
>
> Key: CASSANDRA-5702
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5702
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 2.0 beta 1
>
>
> CASSANDRA-5125 has broken {{ALTER RENAME}} when the column is a default alias
> (for thrift column families where the PK columns haven't been renamed yet).
> The problem is basically that while we assign default aliases to PK columns
> when they don't have one, we currently "fake" those default aliases and do
> not persist them. Concretely, CFDefinition is aware of them, but CFMetaData
> is not, which break renaming post CASSANDRA-5125.
> We could fix rename punctually, but there is another related problem: for the
> same reason, if you try to create an index on a column that is a non-renamed
> default alias, this doesn't work with the arguably confusing message "No
> column definition found for column X". Here again, we could fix it
> punctually, but it starts to sound like we need a more general fix.
> So I suggest stopping to "fake" those default aliases, but instead to just
> create "real" aliases (that are known of CFMetaData and persisted in the
> schema) when there is none. After all, from a user point of view, why should
> a default column name be any special. And on top of fixing the issues above,
> this also:
> # fix CASSANDRA-5489 in a somewhat simpler way
> # makes it easier for clients reading the schema CFs. They won't to infer the
> default aliases anymore.
> The only theoretical downside is that we lose the information that a given
> CQL3 column name is one assigned by default versus one set up by the user,
> but given the user can rename those column names anyway, not sure this
> matters in any way.
--
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
