[
https://issues.apache.org/jira/browse/CASSANDRA-11873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15451804#comment-15451804
]
Sylvain Lebresne commented on CASSANDRA-11873:
----------------------------------------------
bq. it is not always possible to properly order the duration as they rely on
the context.
I'm not readily convinced this is such a problem. The motivation for duration
types (in C*, not in some general sense) is first and foremost (imo) to make it
easier to work with time series. Comparatively, using a duration in a
clustering column (that only where the ordering matters) with some close
reliance on proper ordering doesn't feel that fundamental to me. For instance,
I haven't given it too much though, but we make that type non-comparable (we
have at least one precedent with the counter type), which amounts of forbidding
it in a clustering column. I don't think it would be that big of a deal: you
can use a simple integer if you really need to store a duration in a clustering
column, and we can provide conversions functions to make going from duration to
integers (said conversion could for instance use fixed conversion factors (say
1 month = 30 days, 1 day = 24h etc.., Postregsql uses this when dealing with
fraction of days, which they support) by default with the option for user to
pick some other factor; and don't get me wrong, such functions are totally
material for follow-ups).
bq. I will be in favor of using 2 types but I would like to know your opinion.
A priori, I disagree, because I suspect this would be inferior for most of the
use cases we primarily targeting (user convenience). Splitting into 2 types
just for sorting, when sorting isn't at all the important part, feels wrong to
me. Besides, I don't think it even really solve the problem fully: there is
leap seconds and daylight saving adjustment, so even ordering the 'day to
fraction of second' type can't be perfectly done. Which again, just suggest to
me that a duration type can't be properly ordered and we shouldn't try to: if
you need to order duration, you *have* to normalize them to a number of seconds
(or less) or you're doing it wrong, and we should let user do so (with as much
help as we can) rather than "hack" around that fundamental fact.
> 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)
