cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From " Brian Hess (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-11873) Add duration type
Date Thu, 16 Jun 2016 15:58:05 GMT

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

 Brian Hess commented on CASSANDRA-11873:
-----------------------------------------

I will save the discussion/debate on the relationship between CQL and SQL to another venue.
The reason to bring it up is in the context of user/developer  experience and usability. If
SQL has an approach then we should consider it, but if we can do better then by all means
we should do that instead (which I think nobody is debating). 

A few comments:
1. We should certainly consider the month and year durations. These are common uses and we
should at least sketch out how we would support that (if not also implement it in this ticket
- which I think we should do). 
2. How would we abbreviate the example that Sylvain proposes "1 year 2 months 3 days 4 hours
5 minutes 6 seconds"? Specifically, what is the abbreviation for months and minutes? ISO 8601
has M for both, but the P/T format allows for disambiguation. 
3. With respect to ISO 8601 that Postgres does also support, if someone bothers to read the
CQL documentation on Date formats for Timestamp types he will find that it states "A timestamp
type can be entered as an integer for CQL input, or as a string literal in any of the following
ISO 8601 formats" (https://docs.datastax.com/en/cql/3.3/cql/cql_reference/timestamp_type_r.html).
So, C* already chose ISO 8601 for Date formats. For consistency with CQL itself we should
seriously consider making the same choice for durations. 
4. According to the C* documentation, the TIMESTAMP data type, which is what is returned from
the Now() call, is the "number of milliseconds since the standard base time known as the epoch".
How are we going to support microseconds and nanoseconds? Even Version 1 UUIDs (UUID/TimeUUID
format for C*) don't support nanosecond resolution. 
5. If we choose to stick with the current bespoke syntax, I suggest moving at least to the
Influx format. That leaves 2 items:
a) change microseconds from "us" to "u", which is what Influx uses 
b) support weeks with the "w" abbreviation. 

> Add duration type
> -----------------
>
>                 Key: CASSANDRA-11873
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11873
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: CQL
>            Reporter: Benjamin Lerer
>            Assignee: Benjamin Lerer
>              Labels: client-impacting, doc-impacting
>             Fix For: 3.x
>
>
> For CASSANDRA-11871 or to allow queries with {{WHERE}} clause like:
> {{... WHERE reading_time < now() - 2h}}, we need to support some duration type.
> In my opinion, it should be represented internally as a number of microseconds.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message