[
https://issues.apache.org/jira/browse/CASSANDRA-6643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13888111#comment-13888111
]
Sylvain Lebresne commented on CASSANDRA-6643:
---------------------------------------------
Thinking a bit more about that, I think the right question is whether we want
to allow a table to depend on a type in another keyspace. Currently, you can
(it has been designed for it), and you don't need type renames for that, it's
enough to simply refer to a type using it's fullly qualified name at table
creation. Now, this does present a problem if a keyspace is dropped but
contains types used in another keyspace. I suppose we'd need to check for that
case and refuse the drop in that case. It's not done right now though. And that
does complicate security rules a bit.
But maybe having tables reference types in another keyspace is not that useful
and it's better to keep things simpler and just forbid it. The reason I left
that option initially however was for the case where someone have a type he
uses in multiple keyspace, to avoid having to re-declare it multiple times
(re-declaring the type multiple time is probably not a huge deal in itself, but
that will mean the types will be different which could end up being slightly
annoying on the client driver side if you really want those per-keyspace types
to be the same).
So anyway, I don't think I have an extremely strong opinion on that one. But if
we do let table reference type in another keyspace, it feels relatively natural
to me to let type rename change the keyspace. But if we don't (let table
reference type in another keyspace), then I agree that it's natural to forbid
type rename to change the keyspace.
bq. or at least implicitly name into the same ks implicitly when no ks prefix
is on the rename's 'destination'
When a type name is not fully qualified, it refers to the current keyspace
everywhere else, so I really don't want to make a special case for that one.
Would be confusing for no much value added imo.
> ALTER TYPE RENAME allows renaming to another keyspace
> -----------------------------------------------------
>
> Key: CASSANDRA-6643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6643
> Project: Cassandra
> Issue Type: Bug
> Environment: java version "1.7.0_51"
> cassandra from trunk, 4b54b8...
> Reporter: Russ Hatch
> Priority: Minor
>
> I'm not 100% certain this is a bug.
> The current syntax for "alter type rename" requires the keyspace on the old
> and new table name (if a keyspace is not active). So, to rename the type
> 'foo' to 'bar', you have to issue this statement:
> ALTER TYPE ks.foo rename to ks.bar .
> As a result, this syntax will also allow renaming the type into another
> existing keyspace, which updates the metadata in system.schema_usertypes.
> I'm wondering if perhaps we can omit the second keyspace prefix and
> implicitly rename into the same keyspace.
> To reproduce:
> {noformat}
> cqlsh> create keyspace user_types with replication =
> {'class':'SimpleStrategy', 'replication_factor':3} ;
> cqlsh> create keyspace user_types2 with replication =
> {'class':'SimpleStrategy', 'replication_factor':3} ;
> cqlsh> CREATE TYPE user_types.simple_type (user_number int);
> cqlsh> alter type user_types.simple_type rename to user_types2.simple_type;
> {noformat}
> Renaming to another keyspace is also possible when a keyspace is active, like
> so:
> {noformat}
> cqlsh:user_types> alter type simple_type rename to user_types2.simple_type;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
