Sylvain Lebresne created CASSANDRA-7791:
-------------------------------------------

             Summary: 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
             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