cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joshua McKenzie (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7523) add date and time types
Date Sun, 14 Sep 2014 20:29:34 GMT

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

Joshua McKenzie commented on CASSANDRA-7523:
--------------------------------------------

V1 of the changes is ready for review.

[Cassandra changes|https://github.com/josh-mckenzie/cassandra/compare/7523_squashed]
[Python driver changes|https://github.com/josh-mckenzie/python-driver/compare/7523_squashed]

{quote}
Do we really want to add this in 2.0? This is fairly isolated, but it would be nice to not
introduce new bugs this late in 2.0.
{quote}
Rebased to 2.1.  I agree.

{quote}
Should we be storing dates as four bytes and a days-since-epoch format like postgres? This
would be more compact and allow for a wider range of supported dates.
{quote}
Rewrote based on Integertype, days since epoch.  I used joda for date parsing and formatting
- the built-in java date libraries have a variety of problems that didn't make them suitable
candidates for this work (thread-safety, non-proleptic by default, etc)

{quote}
I feel pretty strongly that the time type should support microsecond resolution, even if we
can't provide microsecond resolution with functions/special values like now until Java 8.
{quote}
I went with nanoseconds since midnight.  It adds the complexity of serialization to and from
string but should add little as far as data footprint on disk with compression enabled and
this prevents us from having to rework a higher resolution type down the line (see CASSANDRA-7536)

{quote}
I wouldn't accept a millis-since-epoch string for dateStringToDate()
{quote}
Done

{quote}
TimeType should not be compatible with DateType and TimestampType (nor should SimpleDateType
if we use a four-byte format)
{quote}
Done

{quote}
I would use "date" instead of "simpledate" in a few places: CQL3Types.Native, Cql3.g (K_SIMPLEDATE),
Constants.Type
{quote}
Done.  I also updated the CQL html help docs to reflect a more consistent naming scheme (timestamp,
date, time)

{quote}
Definitely needs a lot of tests before committing (to whichever branch).
{quote}
Tests for types, serialization, cqlshlib, types in python driver, and integration tests on
driver added.  Let me know if you can think of anything else that could use some testing in
this context.

{quote}
We do want to leave the format the same for timestamps. I would add a new format option for
the "time" type and leave the existing one for timestamps.
{quote}
Done.

Once we get the java side ironed out I'll get the ball rolling on python driver change review/integration
and open another ticket to update the bundled driver to support these new types.

> add date and time types
> -----------------------
>
>                 Key: CASSANDRA-7523
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7523
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API
>            Reporter: Jonathan Ellis
>            Assignee: Joshua McKenzie
>            Priority: Minor
>             Fix For: 2.1.1, 3.0
>
>
> http://www.postgresql.org/docs/9.1/static/datatype-datetime.html
> (we already have timestamp; interval is out of scope for now, and see CASSANDRA-6350
for discussion on timestamp-with-time-zone.  but date/time should be pretty easy to add.)



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

Mime
View raw message