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