[
https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14089417#comment-14089417
]
Joshua McKenzie commented on CASSANDRA-7523:
--------------------------------------------
Thanks for the feedback [~thobbs] - wanted to confirm there wasn't anything
major I'd overlooked when it came to adding new types into the system.
In the context of "minimal impact addition to 2.0.X", I think keeping Time
resolution at ms makes sense though I agree with the point about halving
storage size on Date w/wider reach rather than using sql.Date.
That being said, while this ticket in its current incarnation is *relatively*
simple it also lies at the bottom of the stack in the type system. Given how
late we are in the 2.0.X life cycle, the python driver modifications, and the
pending high resolution type ticket my preference is to push this to 2.1+. We
can implement the Time type here as nanos since midnight since it only costs us
an extra byte over usec and the extra parsing adds nominal complexity, and
finally close CASSANDRA-7536 as duplicate.
I'd prefer not to add a ms resolution Time and clutter the type system with a
high resolution type later or deal with the complexity of data conversion -
better to get it right the first time. Along with that, going w/2.1+ prevents
duplicate work modifying multiple python drivers to support the new types.
> add date and time types
> -----------------------
>
> Key: CASSANDRA-7523
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7523
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Reporter: Jonathan Ellis
> Assignee: Joshua McKenzie
> Priority: Minor
> Fix For: 2.0.10
>
>
> 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.2#6252)
