[
https://issues.apache.org/jira/browse/CASSANDRA-4283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13283576#comment-13283576
]
Sylvain Lebresne commented on CASSANDRA-4283:
---------------------------------------------
bq. First, I don't think trying to guess what the user wants here is the right
solution.
Maybe I'm wrong on what the SQL standard actually does and that's another
problem, but at least in principle I really don't think that what I was
suggesting is in any way ambiguous. If you use '2012-06-06', it feels natural
and straightforward that you expect a day precision. And that if you want any
time after '2012-06-06 00:00:00' then you'd use {{time > '2012-06-06
00:00:00'}}. And if you say, {{time > '2012'}}, likely you want something after
2012. I mean, it reads like that.
That being said, I haven't checked what the SQL standard and if it prescribes
that the query in the description of this ticket is equivalent to:
{noformat}
SELECT * FROM timeline
WHERE k = ...
AND time > '2012-06-06 00:00:00'
AND time <= '2012-06-09 00:00:00'
{noformat}
and thus will return everything done the 6 june 2012, then so be it. That's not
the most natural definition but so be it.
> CQL3: dates are not handled correctly in slices
> ------------------------------------------------
>
> Key: CASSANDRA-4283
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4283
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Affects Versions: 1.1.0
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Labels: cql3
> Fix For: 1.1.2
>
>
> Our timestamp type allows to input timestamp as dates like '2012-06-06'.
> However, those don't work as expected in slice queries, as for instance:
> {noformat}
> SELECT * FROM timeline
> WHERE k = ...
> AND time > '2012-06-06'
> AND time <= '2012-06-09'
> {noformat}
> will return timestamps from '2012-06-06' and not those from '2012-06-09'. The
> reason being of course that we always translate a date the same way, using 0
> for whichever part is not precised.
> A reasonably simple fix could be to add a new fromString(String s, boolean
> gt) method to AbstractType that is used when the the string should be
> interpreted in an inequality (the boolean gt would then say which kind of
> inequality).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
