[
https://issues.apache.org/jira/browse/CASSANDRA-14567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16546669#comment-16546669
]
Benedict commented on CASSANDRA-14567:
--------------------------------------
So, if we look back to the original intent, i.e. CASSANDRA-4851, it's quite
clear that \{{ (c1, c2) >= (1, 10) }} is intended to mean \{ (c1 == 1 AND c2
>= 10) OR c1 > 1 }
This is also the only definition that remains consistent across MVs, secondary
indexes, or matching schemas with different clustering definitions - so this
seems clearly less surprising to the user.
I think the only sane way to support this unintended behaviour is to support
arbitrary intra-partition OR clauses. This actually shouldn't be very
difficult, since all it entails is converting to conjunctive normal form,
building each slice as we do now, then sorting them and checking they are
disjoint (or otherwise merging).
> CQL query returns different results in 2.2.5 and 3.0.15
> -------------------------------------------------------
>
> Key: CASSANDRA-14567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14567
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Reporter: Dikang Gu
> Priority: Major
>
> During our 2.2.5 to 3.0.15 upgrade, we find the a cql query returns different
> results in 2.2.5 and 3.0.15, here is a unit test to reproduce it,
> [https://gist.github.com/DikangGu/e538ed2de22b74e49b8dd43f7093a996]
>
> In C* 2.2.5, it returns all 4 rows: *[Row[1, 10, 0, 1], Row[1, 10, 10, 2],
> Row[1, 1, 0, 3], Row[1, 1, 10, 4]]*
> While in C* 3.0.15, it only returns 2 rows to client: *[Row[1, 10, 0, 1],
> Row[1, 1, 10, 4]]*
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
