cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Stupp (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7791) Consider re-allowing to refer to UDT outside of their keyspace
Date Wed, 03 Sep 2014 16:16:52 GMT


Robert Stupp commented on CASSANDRA-7791:

Note: with CASSANDRA-7812 committed, dropping a function with bad types gives the following
cqlsh:ks1> DROP FUNCTION foo(afeawefawef);
<ErrorMessage code=0000 [Server error] message="java.lang.AssertionError">

> Consider re-allowing to refer to UDT outside of their keyspace
> --------------------------------------------------------------
>                 Key: CASSANDRA-7791
>                 URL:
>             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
> # 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

View raw message