Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Sun, 14 Sep 2014 20:29:34 +0000 (UTC)
From: "Joshua McKenzie (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12726245.1404880380000.31768.1410726574166@Atlassian.JIRA>
In-Reply-To: <JIRA.12726245.1404880380000@Atlassian.JIRA>
References: <JIRA.12726245.1404880380000@Atlassian.JIRA>
 <JIRA.12726245.1404880380055@arcas>
Subject: [jira] [Commented] (CASSANDRA-7523) add date and time types
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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)