[ 
https://issues.apache.org/jira/browse/CASSANDRA-17425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17508758#comment-17508758
 ] 

Benjamin Lerer edited comment on CASSANDRA-17425 at 3/18/22, 12:52 PM:
-----------------------------------------------------------------------

{quote}I do not have objections on extending 'writetime' and 'tty' functions to 
support multi-cell types, although I do doubt how practical it is to return the 
timestamps/TTLs of the entire collection. {quote}
It is a feature that I have seen requested quite often.


{quote}Do you have an ETA on when your patch will land?{quote}
Today or Monday

I had a quick look at the patch that we made for CASSANDRA-8877. It made me 
realized that even for {{maxWritetime}} the situation is may be more 
complicated than it looks at first glance. We apparently have ignored for 
{{writetime}} and {{ttl}} the fact that selectors can be chained and used to 
reduce the selection.
For example:
{code}
SELECT writetime(myMap['second'..'third']), ttl(myUdt.myFirstField) FROM myTable
{code}
The same problem will apply to {{maxTimestamp}} if I am not mistaken.
 
I feel that we should undust our patch has it adressed those problems. Adding 
MaxWritetime on top of it should be relatively straight forward in my opinion.

What do you think?



was (Author: blerer):
{quote}I do not have objections on extending 'writetime' and 'tty' functions to 
support multi-cell types, although I do doubt how practical it is to return the 
timestamps/TTLs of the entire collection. {quote}
It is a feature that I have seen requested quite often.


{quote}Do you have an ETA on when your patch will land?{quote}
Today or Monday

I had a quick look at the patch that we made for CASSANDRA-8877. It made me 
realized that even for {{maxWritetime}} the situation is may be more 
complicated than it looks at first glance. We apparently have ignored for 
{{writetime}} and {{ttl}} the fact that selectors can be chained and used to 
reduce the selection.
For example:
{code}
SELECT writetime(myMap['second'..'third']), ttl(myUdt.myFirstField) FROM myTable
{code}
The same problem will apply to {{maxTimestamp}} if I am not mistaken.
 
I feel that we should undust our patch has it adressed those problems. Adding 
MaxWritetime on top of it should be relatively straight forward in my opinion.


> Add new CQL function maxWritetime
> ---------------------------------
>
>                 Key: CASSANDRA-17425
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-17425
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: CQL/Syntax
>            Reporter: Yifan Cai
>            Assignee: Yifan Cai
>            Priority: Normal
>
> The function "writetime" does not support multi-cell types, e.g. collections 
> and UDT. It would be useful to enable querying the latest modified timestamp 
> of a column value. 
> I'd like to propose to add a new function named "maxWritetime", which returns 
> the largest timestamp amongst the cells. When being applied to the single 
> cell types, it returns the same result as "writetime".



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to