Uploaded image for project: 'Cassandra'
  1. Cassandra
  2. CASSANDRA-7791

Consider re-allowing to refer to UDT outside of their keyspace

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Normal
    • Resolution: Not A Problem
    • Fix Version/s: None
    • Component/s: None
    • Labels:

      Description

      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:

      1. we make UDT accessible anywhere (though their fully qualified name).
      2. we don't support functions on UDT at all.
      3. we make functions keyspace-scoped, either always, or only if they apply to UDT.
      4. 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.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              slebresne Sylvain Lebresne
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: