Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 8 Jul 2013 14:03:48 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12656161.1372925983420.11050.1373292228799@arcas>
In-Reply-To: <JIRA.12656161.1372925983420@arcas>
References: <JIRA.12656161.1372925983420@arcas>
Subject: [jira] [Updated] (CASSANDRA-5723) DateType (timestamp type in CQL3)
 does not sort pre-'unix epoch' dates correctly
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/CASSANDRA-5723?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sylvain Lebresne updated CASSANDRA-5723:
----------------------------------------

    Attachment: 5723.txt

Attaching a patch with that new TimestampType. The patch is against 1.2 rig=
ht now, but I'm starting to wonder if 2.0 is not a more reasonable goal.

The basics of the patch is that the CQL3 timestamp type now default to that=
 new type. For the native protocol however, we make both DateType and Times=
tampType be returned as 'timestamp'. Otherwise, if we were returning it as =
a custom type, this would likely break users since client driver wouldn't r=
ecognize it anymore. Besides, the actual sorting of a type in a ResultSet s=
houldn't matter for a CQL3 driver.

On the CQL-over-thrift side however, we return the full "thrift" comparator=
 name, so in practice we'd have to update cqlsh so it continues to work wit=
h dates, but the patch doesn't do it.

The patch let user switch between DateType and TimestampType, but log a war=
ning when you do so.
               =20
> DateType (timestamp type in CQL3) does not sort pre-'unix epoch' dates co=
rrectly
> -------------------------------------------------------------------------=
-------
>
>                 Key: CASSANDRA-5723
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5723
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.3
>            Reporter: zhouhero
>             Fix For: 1.2.3
>
>         Attachments: 5723.txt
>
>
> - this bug can be confirmed by fellow:
> 1.create table like fellow:
> create table test2 (
> id varchar,
> c varchar,
> create_date timestamp,
> primary key(id)
> );
> create index idx_test2_c on test2 (c);
> create index idx_test2_create_date on test2 (create_date);
> 2.insert data like fellow;
> cqlsh:pgl> update test2 set create_date=3D'1950-01-01', c=3D'1' where id=
=3D'111';
> cqlsh:pgl> update test2 set create_date=3D'1917-01-01', c=3D'1' where id=
=3D'111';
> cqlsh:pgl> update test2 set create_date=3D'2013-01-01', c=3D'1' where id=
=3D'111';
> 3.select data :
> cqlsh:pgl> select * from test2 where c=3D'1' and create_date>'2011-01-01 =
12:00:01' ALLOW FILTERING ;
> id | c | create_date
> -----+---+--------------------------
> 111 | 1 | 2012-12-31 15:00:00+0000
> 4. add data:
> update test2 set create_date=3D'1917-05-01', c=3D'1' where id=3D'111';
> 5.select data:
> cqlsh:pgl> select * from test2 where c=3D'1' and create_date>'2011-01-01 =
12:00:01' ALLOW FILTERING ;
> id | c | create_date
> -----+---+--------------------------
> 111 | 1 | 1917-04-30 15:00:00+0000
> =E2=86=91
> the search result is not right!
> it should be fellow:
> id | c | create_date
> -----+---+--------------------------
> 111 | 1 | 2012-12-31 15:00:00+0000

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira