[jira] [Issue Comment Edited] (CASSANDRA-2530) Additional AbstractType data type definitions to enrich CQL

["Rick Shaw (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-2530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042343#comment-13042343 ] 

Rick Shaw edited comment on CASSANDRA-2530 at 6/1/11 6:44 PM:
--------------------------------------------------------------

{quote}
 Isn't date throwing away information when it encodes to long (the time zone)?
{quote}
I don't think any info is lost. The encoding adjusts the date to UTC based on the (default) locale. The formatting back out again will treat it as stored in UTC and adjust it back to the (default) locale. Arguably fragile. But using it in values (as opposed to names) is the JDBC assumption anyway. Saving 8 bytes as the volumes of rows and columns it is used in, goes into the stratosphere are very compelling. 


{quote}
Also not a fan of copy/pasting the iso patterns, go ahead and reference the copy in TUUIDT, or move those somewhere more generic.
{quote}
Agreed. Patch shares the value in TUUIDT as a {{import static}}. Moving the declaration to say: AbstractType may be better in the long run but the newbie did not want to tamper any more than necessary. 

{quote}
Using compareUnsigned in the boolean compare method seems like overkill.
{quote}
Agreed. A bit too much "sharing"... Patch uses {{o1.compareTo(o2)}}.



      was (Author: ardot):
    {quote}
 Isn't date throwing away information when it encodes to long (the time zone)?
{quote}
I don't think any info is lost. The encoding adjusts the date to UTC based on the (default) locale. The formatting back out again will treat it as stored in UTC and adjust it back to the (default) locale. Arguably fragile. But using it in values (as opposed to names) is the JDBC assumption anyway. 


{quote}
Also not a fan of copy/pasting the iso patterns, go ahead and reference the copy in TUUIDT, or move those somewhere more generic.
{quote}
Agreed. Patch shares the value in TUUIDT as a {{import static}}. Moving the declaration to say: AbstractType may be better in the long run but the newbie did not want to tamper any more than necessary. Saving 8 bytes as the volumes of rows and columns it is used in, goes into the stratosphere are very compelling. 

{quote}
Using compareUnsigned in the boolean compare method seems like overkill.
{quote}
Agreed. A bit too much "sharing"... Patch uses {{o1.compareTo(o2)}}.


  
> Additional AbstractType data type definitions to enrich CQL
> -----------------------------------------------------------
>
>                 Key: CASSANDRA-2530
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2530
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 0.8.0 beta 2
>            Reporter: Rick Shaw
>            Priority: Trivial
>              Labels: cql
>         Attachments: patch-to-add-4-new-AbstractTypes-and-CQL-support-v4.txt, patch-to-add-4-new-AbstractTypes-and-CQL-support-v5.txt
>
>
> Provide 5 additional Datatypes: ByteType, DateType, BooleanType, FloatType, DoubleType.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira