Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Fix Version/s: 1.2.0 beta 1
    • Component/s: API
    • Labels:

      Description

      Currently, in CQL3 and contrarily to SQL, one cannot define a table having only a PK but no other columns. Related to that, a CQL always needs at least one column outside of the PK to be inserted to exist. All that may force people to add 'fake' value that they don't really need.

      The goal of this ticket is to lift that limitation and allow table definition to have only a PK, and to have CQL rows exist even if only the PK has been inserted (in other words, to have CQL rows behave like SQL rows).

      Following CASSANDRA-4329, one way to do that with the sparse-composite encoding CQL3 uses would be to insert as marker of the CQL row presence a CQL column with an empty name (the underlying column name won't be empty though since it's a composite). The drawback though is that we will need to insert that marker with every insert to the CQL row (in other word, we'll add a slight overhead to the size of each write). The pros is that if we have such marker for the CQL row presence, we will be able to reoptimize back queries that select only a few columns (since following CASSANDRA-3982 we query all columns of a CQL row every time).

      1. 4361.txt
        25 kB
        Sylvain Lebresne

        Issue Links

          Activity

          Sylvain Lebresne created issue -
          Sylvain Lebresne made changes -
          Field Original Value New Value
          Link This issue requires CASSANDRA-4329 [ CASSANDRA-4329 ]
          Hide
          Ahmet AKYOL added a comment - - edited

          "Definition with only a PK" is mostly for time series (wide row type) data and in that case "comparators" are the most critical configuration. CQL3 table definitions are mostly like SQL DDL but C* has its own way too.

          AFAIK, we can't define "comparator" with cql3. So, IMHO, this problem can be a sub-task to this issue. Or there can be a special syntax for this type of wide row tables:

          CREATE TABLE ( id varchar PRIMARY KEY ) WITH WIDENING ORDER BY (uuid DESC);
          

          Edit: I've just open an issue for this CASSANDRA-4424

          Show
          Ahmet AKYOL added a comment - - edited "Definition with only a PK" is mostly for time series (wide row type) data and in that case "comparators" are the most critical configuration. CQL3 table definitions are mostly like SQL DDL but C* has its own way too. AFAIK, we can't define "comparator" with cql3. So, IMHO, this problem can be a sub-task to this issue. Or there can be a special syntax for this type of wide row tables: CREATE TABLE ( id varchar PRIMARY KEY ) WITH WIDENING ORDER BY (uuid DESC); Edit: I've just open an issue for this CASSANDRA-4424
          Hide
          Sylvain Lebresne added a comment -

          Attaching a patch for this that does 2 things:

          • It changes the definition of having a row existing for CQL3 from 'the CQL row exists if it has at least one column set (non null) outside of the PK' to 'the CQL row exists if it has a column set'. Concretely, since by definition a PK cannot contain null values, it means a row exists as long as the PK is set. In practice it means that the following is now fine:
              CREATE TABLE foo (k int PRIMARY KEY, c int);
              INSERT INTO foo (k) VALUES (1);
              

            and that

              INSERT INTO foo (k, c) VALUES (2, 2);
              DELETE c FROM foo WHERE k = 2;
              SELECT * FROM foo WHERE k = 2;
              

            will return a result (with k == 2 and c == null) rather than no result.

          • It allows defining a table with only a PK (i.e. 'CREATE TABLE (k in PRIMARY KEY)'). Note that this make sense only thanks to the previous point.

          Note that COMPACT STORAGE definitions are slightly more limited in that they must have a multi-component PK to allow this. I.e. the following is still invalid:

          CREATE TABLE foo (
              k int PRIMARY KEY
          ) WITH COMPACT STORAGE;
          

          but the following is ok:

          CREATE TABLE foo (
              k int,
              c int,
              PRIMARY KEY (k, c)
          ) WITH COMPACT STORAGE;
          
          Show
          Sylvain Lebresne added a comment - Attaching a patch for this that does 2 things: It changes the definition of having a row existing for CQL3 from 'the CQL row exists if it has at least one column set (non null) outside of the PK' to 'the CQL row exists if it has a column set'. Concretely, since by definition a PK cannot contain null values, it means a row exists as long as the PK is set. In practice it means that the following is now fine: CREATE TABLE foo (k int PRIMARY KEY, c int); INSERT INTO foo (k) VALUES (1); and that INSERT INTO foo (k, c) VALUES (2, 2); DELETE c FROM foo WHERE k = 2; SELECT * FROM foo WHERE k = 2; will return a result (with k == 2 and c == null) rather than no result. It allows defining a table with only a PK (i.e. 'CREATE TABLE (k in PRIMARY KEY)'). Note that this make sense only thanks to the previous point. Note that COMPACT STORAGE definitions are slightly more limited in that they must have a multi-component PK to allow this. I.e. the following is still invalid: CREATE TABLE foo ( k int PRIMARY KEY ) WITH COMPACT STORAGE; but the following is ok: CREATE TABLE foo ( k int, c int, PRIMARY KEY (k, c) ) WITH COMPACT STORAGE;
          Sylvain Lebresne made changes -
          Attachment 4361.txt [ 12536185 ]
          Sylvain Lebresne made changes -
          Status Open [ 1 ] Patch Available [ 10002 ]
          Sylvain Lebresne made changes -
          Attachment 4361.txt [ 12536185 ]
          Hide
          Sylvain Lebresne added a comment -

          Attached rebased patch (after CASSANDRA-3647 in particular)

          Show
          Sylvain Lebresne added a comment - Attached rebased patch (after CASSANDRA-3647 in particular)
          Sylvain Lebresne made changes -
          Attachment 4361.txt [ 12537341 ]
          Hide
          Jonathan Ellis added a comment -

          LGTM, +1

          Show
          Jonathan Ellis added a comment - LGTM, +1
          Hide
          Sylvain Lebresne added a comment -

          Committed, thanks

          Show
          Sylvain Lebresne added a comment - Committed, thanks
          Sylvain Lebresne made changes -
          Status Patch Available [ 10002 ] Resolved [ 5 ]
          Reviewer jbellis
          Resolution Fixed [ 1 ]
          Gavin made changes -
          Workflow no-reopen-closed, patch-avail [ 12708011 ] patch-available, re-open possible [ 12750906 ]
          Gavin made changes -
          Workflow patch-available, re-open possible [ 12750906 ] reopen-resolved, no closed status, patch-avail, testing [ 12757418 ]

            People

            • Assignee:
              Sylvain Lebresne
              Reporter:
              Sylvain Lebresne
              Reviewer:
              Jonathan Ellis
            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development