[ 
https://issues.apache.org/jira/browse/CASSANDRA-18078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Williams updated CASSANDRA-18078:
-----------------------------------------
    Description: 
CASSANDRA-17425 added a new {{MAXWRITETIME}} function that allows to retrieve 
the maximum timestamp of a multi-cell column. For example:
{code:java}
> CREATE TABLE t (k int PRIMARY KEY, v set<int>);
> INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> SELECT maxwritetime(v) FROM t;

 maxwritetime(v)
-----------------
             200
{code}
Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of 
each of the cells in a multi-cell column:
{code:java}
> SELECT writetime(v) FROM t;

 writetime(v)
-----------------
 [100, 100, 200]

> SELECT writetime(v[1]) FROM t;

 writetime(v[1])
-----------------
             100
{code}
Quite recently, CASSANDRA-18060 has added generic CQL functions to get the min 
and max items in a collection. Those functions can be used in combination with 
the classic {{writetime}} function to get the same results as the new 
{{maxwritetime}} function:
{code:java}
> SELECT collection_max(writetime(v)) FROM t;

 system.collection_max(writetime(v))
-------------------------------------
                                 200
{code}
Those new functions can also be used to get the min timestamp, or the min/max 
TTL, for which there isn't a specific function:
{code:java}
SELECT collection_min(writetime(v)) FROM t;
SELECT collection_min(writetime(v)) FROM t;
SELECT collection_avg(writetime(v)) FROM t;
SELECT collection_min(ttl(v)) FROM t;
SELECT collection_min(ttl(v)) FROM t;
SELECT collection_avg(ttl(v)) FROM t;
{code}
I think this makes the new {{maxwritetime}} mostly redundant, since the new 
functions can achieve the same results in a more generic way. Since the new 
{{maxwritetime}} function is only on trunk, we should consider whether we want 
to remove it in favour of the generic functions.

  was:
CASSANDRA-17456 added a new {{MAXWRITETIME}} function that allows to retrieve 
the maximum timestamp of a multi-cell column. For example:
{code:java}
> CREATE TABLE t (k int PRIMARY KEY, v set<int>);
> INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> SELECT maxwritetime(v) FROM t;

 maxwritetime(v)
-----------------
             200
{code}
Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of 
each of the cells in a multi-cell column:
{code:java}
> SELECT writetime(v) FROM t;

 writetime(v)
-----------------
 [100, 100, 200]

> SELECT writetime(v[1]) FROM t;

 writetime(v[1])
-----------------
             100
{code}
Quite recently, CASSANDRA-18060 has added generic CQL functions to get the min 
and max items in a collection. Those functions can be used in combination with 
the classic {{writetime}} function to get the same results as the new 
{{maxwritetime}} function:
{code:java}
> SELECT collection_max(writetime(v)) FROM t;

 system.collection_max(writetime(v))
-------------------------------------
                                 200
{code}
Those new functions can also be used to get the min timestamp, or the min/max 
TTL, for which there isn't a specific function:
{code:java}
SELECT collection_min(writetime(v)) FROM t;
SELECT collection_min(writetime(v)) FROM t;
SELECT collection_avg(writetime(v)) FROM t;
SELECT collection_min(ttl(v)) FROM t;
SELECT collection_min(ttl(v)) FROM t;
SELECT collection_avg(ttl(v)) FROM t;
{code}
I think this makes the new {{maxwritetime}} mostly redundant, since the new 
functions can achieve the same results in a more generic way. Since the new 
{{maxwritetime}} function is only on trunk, we should consider whether we want 
to remove it in favour of the generic functions.


> Consider removing MAXWRITETIME function
> ---------------------------------------
>
>                 Key: CASSANDRA-18078
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-18078
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: CQL/Syntax
>            Reporter: Andres de la Peña
>            Priority: Normal
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> CASSANDRA-17425 added a new {{MAXWRITETIME}} function that allows to retrieve 
> the maximum timestamp of a multi-cell column. For example:
> {code:java}
> > CREATE TABLE t (k int PRIMARY KEY, v set<int>);
> > INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> > UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> > SELECT maxwritetime(v) FROM t;
>  maxwritetime(v)
> -----------------
>              200
> {code}
> Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of 
> each of the cells in a multi-cell column:
> {code:java}
> > SELECT writetime(v) FROM t;
>  writetime(v)
> -----------------
>  [100, 100, 200]
> > SELECT writetime(v[1]) FROM t;
>  writetime(v[1])
> -----------------
>              100
> {code}
> Quite recently, CASSANDRA-18060 has added generic CQL functions to get the 
> min and max items in a collection. Those functions can be used in combination 
> with the classic {{writetime}} function to get the same results as the new 
> {{maxwritetime}} function:
> {code:java}
> > SELECT collection_max(writetime(v)) FROM t;
>  system.collection_max(writetime(v))
> -------------------------------------
>                                  200
> {code}
> Those new functions can also be used to get the min timestamp, or the min/max 
> TTL, for which there isn't a specific function:
> {code:java}
> SELECT collection_min(writetime(v)) FROM t;
> SELECT collection_min(writetime(v)) FROM t;
> SELECT collection_avg(writetime(v)) FROM t;
> SELECT collection_min(ttl(v)) FROM t;
> SELECT collection_min(ttl(v)) FROM t;
> SELECT collection_avg(ttl(v)) FROM t;
> {code}
> I think this makes the new {{maxwritetime}} mostly redundant, since the new 
> functions can achieve the same results in a more generic way. Since the new 
> {{maxwritetime}} function is only on trunk, we should consider whether we 
> want to remove it in favour of the generic functions.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to