[ 
https://issues.apache.org/jira/browse/CASSANDRA-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14102408#comment-14102408
 ] 

Sylvain Lebresne commented on CASSANDRA-7791:
---------------------------------------------

bq.  It might be possible that a UDT from one keyspace is not available for a 
table in another keyspace (different DC replication settings for different 
keyspaces)

Schema tables are not subject to replication settings, there are replicate 
everywhere no matter what.

> Consider re-allowing to refer to UDT outside of their keyspace
> --------------------------------------------------------------
>
>                 Key: CASSANDRA-7791
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7791
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>              Labels: cql
>             Fix For: 3.0
>
>
> In CASSANDRA-6643 we decided to make UDT inaccessible outside of their 
> keyspace of definition. Doing so mainly has the advantage that when we drop a 
> keyspace, we don't have to worry its UDT being used in another keyspace. 
> However, this directly conflict with functions (UDF) being global: we can't 
> have functions working on UDT if functions are global and we don't allow UDT 
> access outside their keyspace. Which, I believe, leave us with the following 
> possible options:
> # we make UDT accessible anywhere (though their fully qualified name).
> # we don't support functions on UDT at all.
> # we make functions keyspace-scoped, either always, or only if they apply to 
> UDT.
> # we revert CASSANDRA-6438 and make UDT global.
> In a perfect world I would lean towards 4: the arguments to make UDT 
> keyspace-scoped where not wrong per-se but weak in hindsight given the other 
> options here. It is however basically too late: changing it would be a 
> breaking change so we can't reasonably change this post-2.1.0, and while it's 
> not released yet, it's not a change we can make without substantially 
> delaying the final.
> Option 2 feels rather lame in my book.
> Option 3 feels pretty messy. Having 2 types of UDF, some keyspace-scoped and 
> some that are not would be super confusing. Saying that ll UDF are 
> keyspace-scoped feels limiting, and we would still be somewhat inconsistent 
> with our existing hard-coded functions that are global.
> Which leaves option 1 which might be the most pragmatic. Having to check that 
> UDTs are not used before allowing keyspace drop don't sound like a huge deal 
> to me.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to