[jira] [Commented] (CASSANDRA-7523) add date and time types
[
https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14517246#comment-14517246
]
Robert Stupp commented on CASSANDRA-7523:
-
[~JoshuaMcKenzie] can you add some description about the new types to chapter
_6. Data Type Serialization Formats_ in {{doc/native_protocol_v4.spec}}?
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: 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14517425#comment-14517425 ] Joshua McKenzie commented on CASSANDRA-7523: See CASSANDRA-9214 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: 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504504#comment-14504504 ] Sylvain Lebresne commented on CASSANDRA-7523: - I'm fine with reverting and making it 3.0 only as well. 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504973#comment-14504973 ] Joshua McKenzie commented on CASSANDRA-7523: Reverted on 2.1 branch, created CASSANDRA-9219 to track remainder of what came up in comments here. 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503890#comment-14503890 ] Joshua McKenzie commented on CASSANDRA-7523: Planning on reject of empty BB and protecting sub 4.0 clients as well for 3.0 - going to open other tickets to track that after revert. 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503813#comment-14503813 ] Aleksey Yeschenko commented on CASSANDRA-7523: -- No concerns. 3.0 only WFM. Would really like us to reject empty BB as a valid value there though. 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503617#comment-14503617 ] Joshua McKenzie commented on CASSANDRA-7523: I vote we target 3.0. 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14502751#comment-14502751 ] Sylvain Lebresne commented on CASSANDRA-7523: - bq. Snuck the v4 protocol change into the merge to trunk I'm slightly confused here, I don't see any code that seems to prevent the new codes to be used for older versions of the protocol (v1, v2 and v3). 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503118#comment-14503118 ] Joshua McKenzie commented on CASSANDRA-7523: That was perhaps poorly-phrased on my part. I was referring to documentation in the protocol spec doc in v4, and it turns out I missed adding the serialization format information in there (added option id's). Created CASSANDRA-9214 to track that. 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503206#comment-14503206 ] Aleksey Yeschenko commented on CASSANDRA-7523: -- While this is not committed-committed to an existing version yet, can we make the new types non-emptiable by default? See the last two CASSANDRA-8951 comments. 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[
https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503207#comment-14503207 ] Jonathan Ellis commented on CASSANDRA-7523: --- Should we just keep it to 3.0 since adding it to 2.1 wasn't as harmless as it looked? 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14352667#comment-14352667 ] Sylvain Lebresne commented on CASSANDRA-7523: - bq. Should we instead consider v3's spec frozen and have the formal type ID's for these types be added in as a subtask on CASSANDRA-8043? That one. Adding new codes to v3 would confuse drivers (at least we can't assume it won't). It's ok though, the new types will just be sent as custom types on v3 but drivers that wish so can still support them that way. 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.4 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14349396#comment-14349396 ] Joshua McKenzie commented on CASSANDRA-7523: Looks like we're good to go on the [python driver side|https://github.com/datastax/python-driver/pull/243]. Running the tests one last time and will commit for 2.1.4, assuming nobody has a problem with that. 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.4 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14349590#comment-14349590 ] Joshua McKenzie commented on CASSANDRA-7523: [~slebresne] / [~thobbs]: one last question before I commit [this|https://github.com/apache/cassandra/compare/trunk...josh-mckenzie:7523]. Currently I've modified doc/native_protocol_v3.spec to include Date and Time at 0x0011 and 0x0012 respectively. Should we instead consider v3's spec frozen and have the formal type ID's for these types be added in as a subtask on CASSANDRA-8043? 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.4 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14275812#comment-14275812 ] Joshua McKenzie commented on CASSANDRA-7523: Driver PR discussion: [here|https://github.com/datastax/python-driver/pull/241] Squashed/rebased branch for Cassandra: [here|https://github.com/josh-mckenzie/cassandra/compare/7523_rebase] 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.3 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234410#comment-14234410 ] Joshua McKenzie commented on CASSANDRA-7523: Nits fixed, along with a tiny bit of polish: * reverted TypeSerializer change * fixed seconds not bounds-checking w/out period * Added unit tests to check for that * changed joda license file from CRLF line-endings to LF * rebased both java and python branches * fixed unit test for simple date type in python (hadn't updated for new 2^31 == epoch centered byte-order-comparable) My original plan was to get our house in order on this side, then open a ticket/PR for the python driver changes once we've stabilized. We can then open another ticket for updating the python driver that's packaged with C*, since we can commit the java changes w/out necessarily having driver support. Alternatively we can just sit on this ticket until the python changes get merged in and then push this through; the rebase was clean on the java code. 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: docs Fix For: 2.1.3 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234439#comment-14234439 ] Carl Yeksigian commented on CASSANDRA-7523: --- The original plan sounds good to me -- we just need to get everything in order before 2.1.3 goes out. +1 to the new changeset. 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: docs Fix For: 2.1.3 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234481#comment-14234481 ] Joshua McKenzie commented on CASSANDRA-7523: Created [jira ticket|https://datastax-oss.atlassian.net/browse/PYTHON-190] for python driver changes. 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: docs Fix For: 2.1.3 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233468#comment-14233468 ] Carl Yeksigian commented on CASSANDRA-7523: --- Just a few nits: - TypeSerializer just has whitespace changes, shouldn't be included in changes - We should update the internal driver for cqlsh with this change, otherwise you cannot select the values you inserted - In TimeSerializer, the seconds validity check is skipped if no nanoseconds are included. For example 23:59:60 is allowed, along with 23:59:-1. 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: docs Fix For: 2.1.3 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14143572#comment-14143572 ] Joshua McKenzie commented on CASSANDRA-7523: Updated branches available: [Cassandra changes|https://github.com/josh-mckenzie/cassandra/compare/7523_squashed] [Python driver changes|https://github.com/josh-mckenzie/python-driver/compare/7523_squashed] I've converted both types to support byte-order comparibility. They also no longer accept empty strings and don't validate 0 byte inputs. The TimeType was trivial as it was already bounded to byteorder comparable ranges anyway but the SimpleDateType change deserves a bit of explanation. I went back and forth offline w/benedict about the SimpleDateType change - this implementation uses an unsigned integer w/epoch at 2^31 as our date range which requires some shifting and reliance on arithmetic overflow in Java thanks to the lack of a 1st-class unsigned integer type. On top of that, the defined range is different than epoch is 0 that most people might expect. We could use the drivers to mask this and shift values to epoch at zero (which I didn't do in the attached python driver changes); I dislike implementation details of our internal treatment of dates pressuring non-idiomatic external treatments of data in this way but it goes so far as the drivers where they have the freedom to implement as they see fit. It's something I'm willing to accept for the benefits it gives us. I've also added more unit tests surrounding the types and their comparison and updated the cqlshlib unit tests and python driver unit tests to also conform to the new range expectations. 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14143616#comment-14143616 ] Benedict commented on CASSANDRA-7523: - To clarify, all we are doing is defining dates as an unsigned integer, with the epoch being the _minimum_ representable date as opposed to the _middle_. This means any language without unsigned integer support has to do some minor fiddling, but this is not particularly obtuse for writing a network client, and I wouldn't call it foisting internal treament of dates upon the drivers in any unreasonable way. 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14143647#comment-14143647 ] Joshua McKenzie commented on CASSANDRA-7523: The current implementation retains the same range of dates as the previous, 4 bytes worth of days with epoch at the center. Before, the center was 0 on a signed integer, and now epoch is shifted by Integer.MIN_VALUE so we can treat the data type as unsigned for purposes of comparability. I'd prefer we have a date range that extends beyond epoch as our minimum representable date. 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14137366#comment-14137366 ] Joshua McKenzie commented on CASSANDRA-7523: Sit tight on the review on this for a few Tyler - I'm incorporating some of the above changes. Spoke briefly w/Benedict offline; our Time type is byte-order-comparable out of the gate since we're bounding it between 0-N, with N being nanos per day, and I should be able to get SimpleDate into the same boat without too much added complexity. 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135807#comment-14135807 ] Benedict commented on CASSANDRA-7523: - A few quick comments: * You should use TimeUnit.HOURS etc instead of creating static variables and multiplying by them (incl millisPerDay) * Why getMillisAtMidnight()? Doesn't seem to be used, but uses Calendar * It would be nice to make these values byte-order comparable up front, although we can take care of it as part of the later work to be able to transform all bytes to such representations. But it would be preferable to make this one byte-order comparable without conversion, since we have the opportunity. This can be achieved with a simple offset, starting the minimum value at 0, or shifting 0 to MIN_VALUE. i.e. add Integer/Long.MIN_VALUE to any value you would currently generate. * Do we need to support empty values on new types? seems to me we could explicitly forbid them, or would thrift clients still expect to be able to set this to empty? What's to stop is introducing semantics for new types that prevent this, so we can start stamping it out? 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[
https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135921#comment-14135921
]
Joshua McKenzie commented on CASSANDRA-7523:
Pushed an updated branch.
{quote}You should use TimeUnit.HOURS etc instead of creating static variables
and multiplying by them (incl millisPerDay){quote}
Updated to use TimeUnit enum. Much cleaner abstraction - thanks for pointing
that out.
{quote}Why getMillisAtMidnight()? Doesn't seem to be used, but uses
Calendar{quote}
calendar threadlocal and that method were vestigial from some other interim
work and I overlooked that while reviewing - I've removed it.
{quote}It would be nice to make these values byte-order comparable up front,
although we can take care of it as part of the later work to be able to
transform all bytes to such representations.{quote}
Since the discussion is still ongoing and we don't know what form things are
going to stabilize in, I'd prefer to keep the complexity of dealing with /
preparing for a constraint of byte-order comparability in a separate effort.
This also helps keep the code-base consistent as we won't have some types that
are refactored to support different storage constraints, some that aren't.
{quote}Do we need to support empty values on new types? seems to me we could
explicitly forbid them, or would thrift clients still expect to be able to set
this to empty? What's to stop is introducing semantics for new types that
prevent this, so we can start stamping it out?{quote}
Good question. I went with an implementation that was consistent with the rest
of the code-base but can see the argument either way.
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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136054#comment-14136054 ] Benedict commented on CASSANDRA-7523: - bq. I'd prefer to keep the complexity of dealing with / preparing for a constraint of byte-order comparability Well, it's already a beneficial characteristic, as it results in faster comparator operation in 2.1, so it's not about preparation for a future constraint. It also doesn't in any way change how you serialize, it only requires that you change your base value calculation, which is completely arbitrary (you've picked zero; if you pick MIN_VALUE and use ByteBufferUtil.compare() instead of LongType.compare(), everything suddenly works). You can still delegate serialization to the primitive types, so this isn't really any added complexity, it's just making things better off the bat for zero extra cost. As icing on top it avoids needing to do any future conversion to deliver byte order comparisons (which is an unnecessary cost). TL;DR: we shouldn't be perpetuating prior mistakes in new code when we can avoid them for free. 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136070#comment-14136070 ] Benedict commented on CASSANDRA-7523: - bq. Do we need to support empty values on new types? seems to me we could explicitly forbid them, or would thrift clients still expect to be able to set this to empty? What's to stop is introducing semantics for new types that prevent this, so we can start stamping it out? bq. Good question. I went with an implementation that was consistent with the rest of the code-base but can see the argument either way. [~slebresne] [~iamaleksey] any thoughts on this? 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136099#comment-14136099 ] Benedict commented on CASSANDRA-7523: - One last thought to consider: just wondering if it actually makes sense to be using primitive types as the type parameter to AbstractType/TypeSerializer. Why not the joda time types? Generally makes me more comfortable to use stronger types where possible 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136268#comment-14136268 ] Aleksey Yeschenko commented on CASSANDRA-7523: -- Allowing empty values was a mistake in the first place. Shouldn't allow it here, even if it breaks consistency. 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[
https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[
https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14114249#comment-14114249
]
Joshua McKenzie commented on CASSANDRA-7523:
Testing 2 tables w/mirrored inserts, compression enabled, 1 w/5 bigint per row
and 1 w/5 nanotime (6 byte underlying type) per row at 10M inserts (after
forced flush and major compaction to a single file):
{noformat}
12915616 timetest-longtest-ka-37-Filter.db
22044 timetest-longtest-ka-37-Index.db
238827449 timetest-longtest-ka-37-Data.db
105230 timetest-longtest-ka-37-CompressionInfo.db
9991 timetest-longtest-ka-37-Statistics.db
1565712 timetest-longtest-ka-37-Summary.db
12230912 timetest-timetest-ka-35-Filter.db
20040 timetest-timetest-ka-35-Index.db
236028269 timetest-timetest-ka-35-Data.db
92998 timetest-timetest-ka-35-CompressionInfo.db
9983 timetest-timetest-ka-35-Statistics.db
1409144 timetest-timetest-ka-35-Summary.db
452Mlongtest-b884c4c02ed811e4bd586fd6b0389ebc
430Mtimetest-b89d7ce02ed811e4bd586fd6b0389ebc
{noformat}
I expected compression to mostly remove the differential in size as 2 bytes
worth of the most significant bits in the long aren't used when serializing
nanos and it looks like that's the case. The only other justification I can
think of for using a custom 6-byte type is to save the 2 bytes on the wire per
record; I'm inclined to say that the added complexity both server and
client-side to handle a non-standard data type outweigh the potential benefit.
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.2#6252)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14087369#comment-14087369 ] Sylvain Lebresne commented on CASSANDRA-7523: - bq. Do we really want to add this in 2.0? I would agree that it makes more sense to keep that 2.1+ at this point. 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[
https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14086978#comment-14086978
]
Tyler Hobbs commented on CASSANDRA-7523:
Some initial thoughts:
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.
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.
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.
Comments on the patch:
* I wouldn't accept a millis-since-epoch string for {{dateStringToDate()}}
* TimeType should not be compatible with DateType and TimestampType (nor should
SimpleDateType if we use a four-byte format)
* I would use date instead of simpledate in a few places: CQL3Types.Native,
Cql3.g (K_SIMPLEDATE), Constants.Type
Definitely needs a lot of tests before committing (to whichever branch).
bq. Is it reasonable to consider the new Date and Time types DATETIME w/regards
to PEP249?
I think it's reasonable for Date but not Time (although the PEP is kind of
vague).
bq. I don't like changing the ui-time_format cqlshrc option underneath people
but if we add a time type and time_format points to timestamp...
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.
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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14079986#comment-14079986 ] Joshua McKenzie commented on CASSANDRA-7523: Looks like the cqlshlib tests are in need of some attention - I'll take a look at that along w/adding in 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14076793#comment-14076793 ] Joshua McKenzie commented on CASSANDRA-7523: I ended up going outside scope of strictly C* changes on this while testing - here's a snapshot of what I have thus far: * [cql-internal python driver changes|https://github.com/josh-mckenzie/cql-internal/compare/7523] * [cqlshlib and cqlsh changes|https://github.com/josh-mckenzie/cassandra/compare/7523_cqlshlib] * [Java type addition|https://github.com/josh-mckenzie/cassandra/compare/7523_java_types_only] * [Combined commit, new cql-internal archive|https://github.com/josh-mckenzie/cassandra/compare/7523_combined] A few points I could use some feedback on: # Is it reasonable to consider the new Date and Time types DATETIME w/regards to PEP249? # What kind of conversion enforcement do we want on SimpleDate and Time types? I'm thinking reduction only w/warning on both, promotion to Timestamp w/Date object. # I don't like changing the ui-time_format cqlshrc option underneath people but if we add a time type and time_format points to timestamp... I still have some testing to implement (cqlsh, unit, potentially python driver if we merge these changes in) but wanted to get this out there to get feedback since this is a new area of the code-base for me. 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058929#comment-14058929 ] Joshua McKenzie commented on CASSANDRA-7523: Are we shooting for microsecond or millisecond resolution on the time type? 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[
https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059027#comment-14059027
]
Robert Stupp commented on CASSANDRA-7523:
-
Why not add extra resolution in terms of microsecond or even nanosecond
precision. I don't want to bring extra complexity but providing the existing
(low resolution) timestamp plus a high resolution (nano precision)
timestamp plus high resolution time plus date doesn't sound that bad. The new
Java 8 {{java.time}} API brings nanosecond precision - so people might want to
persist that using some natively supported type.
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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059069#comment-14059069 ] Joshua McKenzie commented on CASSANDRA-7523: Pre-Java 8 there really isn't much support for microsecond resolution in the Java ecosystem. I'd prefer we add equivalent (to the current) resolution Date and Time types immediately and look at introducing high-resolution types w/a dependency on Java 8 as a separate effort, giving the new version some time to stabilize. 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059109#comment-14059109 ] Robert Stupp commented on CASSANDRA-7523: - OK - I've created a new ticket CASSANDRA-7536 to cover high precision 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14056150#comment-14056150 ] Sylvain Lebresne commented on CASSANDRA-7523: - One small concern is the native protocol. As there will be no specific cause for those, they will be sent as custom types (i.e the full AbstractType class name will be sent). It's not a huge deal, clients can special case based on the class name, but maybe we could shove codes for those in the protocol v3 before 2.1 final is released (that is, we'll ask drivers to support those types in v3 even though we might really support them only in say 2.1.1). I don't know. 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)
[jira] [Commented] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14056263#comment-14056263 ] Benedict commented on CASSANDRA-7523: - +1 on introducing these; they are often much simpler to reason about and query than timestamp 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)
