[
https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14503202#comment-14503202
]
Sylvain Lebresne commented on CASSANDRA-7523:
---------------------------------------------
The thing is, I don't care too much about the spec documentation itself (it's
important of course, but it's easily fixed). The problem is that if someone use
one of those new data types with an existing client, Cassandra will currently
happily return the new codes, which clients have no reason to know about and
may therefore crash in unexpected ways. *That* is a problem and that's what I
meant by "Adding new codes to v3 would confuse drivers".
So what I mean is that we should special case those 2 types in {{DataType}}
(maybe in {{toType}}, maybe directly in the serialization) so that when the
protocol version is <= 3, then it write the types as {{CUSTOM}} ones. As far as
Cassandra 2.1 is concerned, we could even go as far as remove the types from
{{DataType}} and directly use {{DataType.CUSTOM}} unconditionally since there
won't be support for protocol v4 anyway.
> 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
> Labels: client-impacting, docs
> Fix For: 2.1.5
>
>
> 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)
