mirror of
https://github.com/scylladb/scylladb.git
synced 2026-04-21 09:00:35 +00:00
509626fe08
`duration` is a new native type that was introduced in Cassandra 3.10 [1]. Support for parsing and the internal representation of the type was added in8fa47b74e8. Important note: The version of cqlsh distributed with Scylla does not have support for durations included (it was added to Cassandra in [2]). To test this change, you can use cqlsh distributed with Cassandra. Duration types are useful when working with time-series tables, because they can be used to manipulate date-time values in relative terms. Two interesting applications are: - Aggregation by time intervals [3]: `SELECT * FROM my_table GROUP BY floor(time, 3h)` - Querying on changes in date-times: `SELECT ... WHERE last_heartbeat_time < now() - 3h` (Note: neither of these is currently supported, though columns with duration values are.) Internally, durations are represented as three signed counters: one for months, for days, and for nanoseconds. Each of these counters is serialized using a variable-length encoding which is described in version 5 of the CQL native protocol specification. The representation of a duration as three counters means that a semantic ordering on durations doesn't exist: Is `1mo` greater than `1mo1d`? We cannot know, because some months have more days than others. Durations can only have a concrete absolute value when they are "attached" to absolute date-time references. For example, `2015-04-31 at 12:00:00 + 1mo`. That duration values are not comparable presents some difficulties for the implementation, because most CQL types are. Like in Cassandra's implementation [2], I adopted a similar strategy to the way restrictions on the `counter` type are checked. A type "references" a duration if it is either a duration or it contains a duration (like a `tuple<..., duration, ...>`, or a UDT with a duration member). The following restrictions apply on durations. Note that some of these contexts are either experimental features (materialized views), or not currently supported at run-time (though support exists in the parser and code, so it is prudent to add the restrictions now): - Durations cannot appear in any part of a primary key, either for tables or materialized views. - Durations cannot be directly used as the element type of a `set`, nor can they be used as the key type of a `map`. Because internal ordering on durations is based on a byte-level comparison, this property of Cassandra was intended to help avoid user confusion around ordering of collection elements. - Secondary indexes on durations are not supported. - "Slice" relations (<=, <, >=, >) are not supported on durations with `WHERE` restrictions (like `SELECT ... WHERE span <= 3d`). Multi-column restrictions only work with clustering columns, which cannot be `duration` due to the first rule. - "Slice" relations are not supported on durations with query conditions (like `UPDATE my_table ... IF span > 5us`). Backwards incompatibility note: As described in the documentation [4], duration literals take one of two forms: either ISO 8601 formats (there are three), or a "standard" format. The ISO 8601 formats start with "P" (like "P5W"). Therefore, identifiers that have this form are no longer supported. Fixes #2240. [1] https://issues.apache.org/jira/browse/CASSANDRA-11873 [2]bfd57d13b7[3] https://issues.apache.org/jira/browse/CASSANDRA-11871 [4] http://cassandra.apache.org/doc/latest/cql/types.html#working-with-durations