Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Fix Version/s: 2.1 beta1
    • Component/s: API, Core
    • Labels:
      None

      Description

      A typical use case for a collection could be to store a bunch of addresses in a user profile. An address could typically be composed of a few properties: say a street, a city, a postal code and maybe a few phone numbers associated to it.

      To model that currently with collections, you might use a map<string, blob>, where the map key could be a string identifying the address, and the value would be all the infos of an address serialized manually (you can use text instead of blob and shove everything in a string if you prefer but the principle is the same).

      This ticket suggests to make this more user friendly by allowing:

      CREATE TYPE address (
        street text,
        city text,
        zip_code int,
        phones set<text>
      )
      
      CREATE TABLE users (
        id uuid PRIMARY KEY,
        name text,
        addresses map<string, address>
      )
      

      Under the hood, that type declaration would just be metadata on top of CompositeType (which does mean a limitation would be that we wouldn't allow re-ordering or removal of fields in a custom TYPE). Namely, the address type would be in practice a CompositeType(UTF8Type, UTF8Type, Int32Type, SetType(UTF8Type)) + some metadata that records the name of each component. In other words, this would mostly be user-friendly syntactic sugar to create composite blobs.

      I'll note that this would also be useful outside collections, as it might sometimes be more efficient/useful to have such simple composite blob. For instance, you could imagine to have a:

      CREATE TYPE fullname (
        firstname text,
        lastname text
      )
      

      and to rewrite the users table above as

      CREATE TABLE users (
        id uuid PRIMARY KEY,
        name fullname,
        addresses map<string, address>
      )
      

      In terms of inserts we'd need a syntax for those new "struct". Could be:

      INSERT INTO users (id, name)
                 VALUES (2ad..., { firstname: 'Paul', lastname: 'smith'});
      UPDATE users
         SET addresses = address + { 'home': { street: '...', city: 'SF', zip_code: 94102, phones: {} } }
         WHERE id=2ad...;
      

      where the difference with a map is that the "key" would be a column name (in the CQL3 sense), not a value/literal. Though we might find that a bit confusing and find some other syntax.

      On the query side, we could optionally allow things like:

      SELECT name.firstname, name.lastname FROM users WHERE id=2ad...;
      

      One open question however is what type do we send back in the result set
      for a query like:

      SELECT name FROM users WHERE id=2ad...;
      

      We could:

      1. return just that it's the user defined type named address, but that imply the client has to query the cluster metadata to find out the definition of the type.
      2. return the full definition of the type every time.

      I also note that client side, it might be a tad harder to support such types cleanly in statically type languages than in dynamically typed ones, but that's not the end of the world either.

        Issue Links

          Activity

          Sylvain Lebresne made changes -
          Fix Version/s 2.1 beta1 [ 12326275 ]
          Fix Version/s 2.1 [ 12324159 ]
          Mikhail Stepura made changes -
          Link This issue relates to CASSANDRA-6705 [ CASSANDRA-6705 ]
          Aleksey Yeschenko made changes -
          Link This issue relates to CASSANDRA-6438 [ CASSANDRA-6438 ]
          Ryan McGuire made changes -
          Link This issue relates to CASSANDRA-6312 [ CASSANDRA-6312 ]
          Aleksey Yeschenko made changes -
          Link This issue relates to CASSANDRA-6305 [ CASSANDRA-6305 ]
          Aleksey Yeschenko made changes -
          Link This issue relates to CASSANDRA-6304 [ CASSANDRA-6304 ]
          Sylvain Lebresne made changes -
          Status Patch Available [ 10002 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Aleksey Yeschenko made changes -
          Attachment ocd-and-corrections-patch.txt [ 12611383 ]
          Aleksey Yeschenko made changes -
          Status Open [ 1 ] Patch Available [ 10002 ]
          Brandon Williams made changes -
          Status Testing [ 10012 ] Open [ 1 ]
          Anonymous made changes -
          Status Patch Available [ 10002 ] Testing [ 10012 ]
          Jonathan Ellis made changes -
          Status Open [ 1 ] Patch Available [ 10002 ]
          Jonathan Ellis made changes -
          Reviewer Aleksey Yeschenko [ iamaleksey ]
          Sylvain Lebresne made changes -
          Assignee Sylvain Lebresne [ slebresne ]
          Jonathan Ellis made changes -
          Field Original Value New Value
          Fix Version/s 2.1 [ 12324159 ]
          Component/s API [ 12313742 ]
          Component/s Core [ 12312978 ]
          Sylvain Lebresne created issue -

            People

            • Assignee:
              Sylvain Lebresne
              Reporter:
              Sylvain Lebresne
              Reviewer:
              Aleksey Yeschenko
            • Votes:
              1 Vote for this issue
              Watchers:
              20 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development