[
https://issues.apache.org/jira/browse/CASSANDRA-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4881:
----------------------------------------
Attachment: 4881.txt
I think there is indeed one thing that should be improved, but I'm not sure
this is what you think :)
Currently, the {{CLUSTERING ORDER BY (event_timestamp DESC)}} is a shorthand
for {{CLUSTERING ORDER BY (event ASC, event_timestamp DESC)}}. This isn't very
clear however and so I think we should refuse the former and require the
latter. Attaching a patch to do that.
Now with the caveat above, the rest work as designed. If you don't specify any
ordering for your request (like in the select above), we are free to return
what's most convenient and in practice we return row in disk order. But since
the disk order will be pretty much the one of the inserts (because 'start'
sorts before 'stop', which trumps any sorting for event_timestamp in that
example), the result is correct.
To have things sorted by event_timestamp independently of the event, you will
have to put the {{event_timestamp}} before {{event}} in the primary key
definition.
> Selecting records on a reversed column in CQL 3 returns wrong row
> -----------------------------------------------------------------
>
> Key: CASSANDRA-4881
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4881
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 1.2.0 beta 1
> Reporter: Patrick McFadin
> Assignee: Sylvain Lebresne
> Attachments: 4881.txt
>
>
> Using this table:
> CREATE TABLE video_event (
> videoid_username varchar,
> event varchar,
> event_timestamp timestamp,
> video_timestamp timestamp,
> PRIMARY KEY (videoid_username, event, event_timestamp)
> )WITH CLUSTERING ORDER BY (event_timestamp DESC);
> Inserting these records:
> INSERT INTO video_event (videoid_username, event, event_timestamp,
> video_timestamp)
> VALUES ('99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd','start','2012-09-02
> 18:05:00','2012-09-02 18:05:00');
> INSERT INTO video_event (videoid_username, event, event_timestamp,
> video_timestamp)
> VALUES ('99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd','stop','2012-09-02
> 18:05:30','2012-09-02 18:05:30');
> INSERT INTO video_event (videoid_username, event, event_timestamp,
> video_timestamp)
> VALUES ('99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd','start','2012-09-02
> 18:35:00','2012-09-02 18:35:00');
> INSERT INTO video_event (videoid_username, event, event_timestamp,
> video_timestamp)
> VALUES ('99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd','stop','2012-09-02
> 18:37:30','2012-09-02 18:37:30');
> Running this select:
> select * from video_event where videoid_username =
> '99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd' limit 1;
> I get this:
> videoid_username | event | event_timestamp
> | video_timestamp
> --------------------------------------------+-------+--------------------------+--------------------------
> 99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd | start | 2012-09-02
> 18:05:00+0000 | 2012-09-02 18:05:00+0000
> I would expect to see this:
> videoid_username | event | event_timestamp
> | video_timestamp
> --------------------------------------------+-------+--------------------------+--------------------------
> 99051fe9-6a9c-46c2-b949-38ef78858dd0:ctodd | stop | 2012-09-02
> 18:37:30+0000 | 2012-09-02 18:37:30+0000
> where the first record pulled was the sorted record by event_timestamp in
> reverse order.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
