[YCQL] Selecting TTL values for collections/UDTs must be supported

[aravind-nallan-yb]

Jira Link: DB-868

ycqlsh:vdf> create KEYSPACE testks WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};
ycqlsh:vdf> use testks;
ycqlsh:testks> CREATE TYPE my_udt(c text, d integer);
ycqlsh:testks> create table test(a integer PRIMARY KEY, b my_udt) WITH default_time_to_live = 15;
ycqlsh:testks> insert into test(a, b) values (10, {c : 'hello' , d : 10});
ycqlsh:testks> select * from test;

 a  | b
----+---------------------
 10 | {c: 'hello', d: 10}

(1 rows)
ycqlsh:testks> select ttl(b) from test;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid Arguments. Input argument for ttl is of wrong datatype
select ttl(b) from test;
           ^
 (ql error -304)"
ycqlsh:testks> select ttl(b.c) from test;
SyntaxException: Invalid SQL Statement. Qualified name not allowed for column reference
select ttl(b.c) from test;
           ^
 (ql error -11)

[aravind-nallan-yb]

Cassandra 3.0 only supports frozen UDTs

cqlsh:vdf> create type attrs ( a1 int, a2 int, a3 int); cqlsh:vdf> create table record ( pk int, cc int, attr attrs, primary key (pk, cc)); InvalidRequest: Error from server: code=2200 [Invalid query] message="Non-frozen User-Defined types are not supported, please use frozen<>"

So there is no question of setting TTLs at individual element level in a UDT. Hence no question of what it'll do when each element has a different TTL and you ask for the TTL at the UDT level. @nocaway @kmuthukk

Also C* doesn't support asking for TTL at element level in a UDT.

cqlsh:vdf> select ttl(attr.a1) from record; SyntaxException: line 1:15 missing ')' at '.' (select ttl(attr[.]a1...)

[m-iancu]

@aravind-nallan-yb As far as I remember, it is intentional that we don't allow the ttl() function on collections because different elements in a collection could have different TTLs.
Therefore, we could not define a clear semantics for ttl() on a collection.

Some notes:

1. TTL can be set on collection elements in YCQL.
   https://github.com/yugabyte/yugabyte-db/blob/master/java/yb-cql/src/test/java/org/yb/cql/TestTTLSemantics.java#L460
2. We have explicit tests for disallowing ttl() on collections
   https://github.com/yugabyte/yugabyte-db/blob/master/java/yb-cql/src/test/java/org/yb/cql/TestSelect.java#L808
3. Note that setting ttl on collections does work in cassandra 3.11/3.10 that we are based on -- though it may not have been supported in the older 3.0 release. For example, copying from my shell (Cassandra 3.11.8):

$ cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.8 | CQL spec 3.4.4 | Native protocol v4]
Use HELP for help.
cqlsh> use sample;
cqlsh:sample> create type attrs ( a1 int, a2 int, a3 int);
cqlsh:sample> create table record ( pk int, cc int, attr attrs, primary key (pk, cc));
cqlsh:sample> update record using ttl 10 set attr.a1 = 2 where pk = 2 and cc = 3;
cqlsh:sample> select * from record;

 pk | cc | attr
----+----+-----------------------------
  2 |  3 | {a1: 2, a2: null, a3: null}

(1 rows)
cqlsh:sample>  -- wait 10+ seconds
cqlsh:sample> select * from record;

 pk | cc | attr
----+----+-----------------------------
  2 |  3 | {a1: 2, a2: null, a3: null}

(1 rows)
cqlsh:sample> select * from record;

 pk | cc | attr
----+----+------

(0 rows)

To go back to the original question on retrieving the TTL using the ttl() function, vanilla Cassandra 3.11 actually does allow the ttl() syntax for collections, but the semantics is arguably not consistent/clear:

cqlsh:sample> create table test(k int primary key, v1 int, v2 attrs, v3 frozen<attrs>);
cqlsh:sample> insert into test(k, v1, v2, v3) values (1, 2, {a1: 1, a2 : 2, a3 : 3}, {a1 : 4, a2: 5, a3 : 6}) using ttl 60;
cqlsh:sample> select ttl(v1), ttl(v2), ttl(v3) from test;

 ttl(v1) | ttl(v2) | ttl(v3)
---------+---------+---------
      47 |    null |      47

(1 rows)

As you can see the ttl for the single value and the frozen collection (also encoded as a single value) is as expected.
However, for the unfrozen collection it's just null.
In Yugabyte, the same example for a non-frozen collection will intentionally error out.
For the frozen collection, I think in theory it can be supported with clear semantics, but currently we still error out in that case too.
For non-collection types it should work as expected.

@aravind-nallan-yb Maybe I misunderstood or misremembered something above. Could you verify if the above makes sense?