[jira] [Commented] (CASSANDRA-7020) Incorrect result of query WHERE token(key) < -9223372036854775808 when using Murmur3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14712790#comment-14712790
]
Piotr Kołaczkowski commented on CASSANDRA-7020:
---
I'm fine leaving it as is for now - I filed the ticket because it felt
surprising at that moment, but now we have a workaround. So maybe just
documenting the special minToken case in the CQL docs on tokens would be enough
for now?
What I don't like about the present state of handling tokens by CQL is that in
some cases it treats tokens as if there was total ordering and in some cases
like here - it doesn't. So for example querying for [a, b) where b < a yields
an empty result (doesn't wrap around). That's why the application has to unwrap
the range manually anyways and fetch a wrapping token range with 2 separate
queries. Unfortunately after unwrapping you get a mintoken on the split point
and then you realize that mintoken actually wraps around and selects
everything. This is how we ended up with a bug in our code.
If it always did wrap-around, that would be IMHO consistent, but we needed to
probably disallow open-ended queries for tokens i.e. "token(...) >= a" without
a corresponding "token(...) < b" clause, as they would always return the full
ring.
> Incorrect result of query WHERE token(key) < -9223372036854775808 when using
> Murmur3Partitioner
> ---
>
> Key: CASSANDRA-7020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7020
> Project: Cassandra
> Issue Type: Bug
> Environment: cassandra 2.0.6-snapshot
>Reporter: Piotr Kołaczkowski
>Assignee: Marko Denda
> Fix For: 2.1.x
>
> Attachments: 7020.txt
>
>
> {noformat}
> cqlsh:test1> select * from test where token("key") < -9223372036854775807;
> (0 rows)
> cqlsh:test1> select * from test where token("key") < -9223372036854775808;
> key | value
> -+--
>5 | ee
> 10 |j
>1 |
>8 |
>2 | bbb
>4 | dd
>7 |
>6 | fff
>9 |
>3 |c
> {noformat}
> Expected: empty result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7020) Incorrect result of query WHERE token(key) < -9223372036854775808 when using Murmur3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14712692#comment-14712692
]
Sylvain Lebresne commented on CASSANDRA-7020:
-
Not so fast: this patch is broken and I think more consideration of this change
is required.
As explain by the code comment, the main intent of the condition is to handle
case like \[a, b\] where b < a. The condition of the patch
({{(startToken.isMinimum() && endToken.isMinimum() && (cmp > 0 || (cmp ==
0)))}} doesn't handle that at all anymore (it *only* handle the min token).
Condition that is, btw, unecessary complex since {{startToken.isMinimum() &&
endToken.isMinimum()}} *implies* that {{cmp == 0}}.
Further, the original reason of this special case is that the min token acts
both as a min and a max for token ranges. This is the way it works internally
and that's the reason it has been done that way in CQL as the expectation was
that client code would probably mimick the way token range are handled in C*
anyway (and that's true of the java driver in particular which does represent
the full ring as the range of (minToken, minToken]). This means in turn that
querying everything in the range (minToken, minToken] returns the whole ring
and that's the reason for the results on this ticket.
Now, I'm not trying to say that all this is very intuitive, it's not, and it is
to some extend inconsistent. What I'm saying however is that:
# the fact that the token ring in cassandra isn't a total order (the min token
is both the min and max) is a bit of a mismatch with CQL, but we still want to
support token somehow and that is bound to be imperfect.
# whether the current solution is the best one or not, changing it is a
breaking change and that requires careful consideration. In particular, it
would not be appropriate to do so in 2.1 at this point.
Now, my personal opinion is that it's not worth bothering with changing this
behavior at this point. Yes, the example of the description is undoubtedly
surprising the first time you encounter it, but at the same time, the min token
*is* a special token in Cassandra and if you work with tokens, you'd better
learn that sooner than later. Or to put it another way, changing this might be
more consistent for CQL, but it won't be perfect either since it will mismatch
with how tokens actually work in Cassandra, so between 2 imperfect solutions,
I'd rather stick with the one that don't imply breaking backward compatibility.
I don't feel terribly strongly about it though and that's certainly up for
debate.
> Incorrect result of query WHERE token(key) < -9223372036854775808 when using
> Murmur3Partitioner
> ---
>
> Key: CASSANDRA-7020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7020
> Project: Cassandra
> Issue Type: Bug
> Environment: cassandra 2.0.6-snapshot
>Reporter: Piotr Kołaczkowski
>Assignee: Marko Denda
> Fix For: 2.1.x
>
> Attachments: 7020.txt
>
>
> {noformat}
> cqlsh:test1> select * from test where token("key") < -9223372036854775807;
> (0 rows)
> cqlsh:test1> select * from test where token("key") < -9223372036854775808;
> key | value
> -+--
>5 | ee
> 10 |j
>1 |
>8 |
>2 | bbb
>4 | dd
>7 |
>6 | fff
>9 |
>3 |c
> {noformat}
> Expected: empty result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7020) Incorrect result of query WHERE token(key) < -9223372036854775808 when using Murmur3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14712691#comment-14712691
]
Jeremiah Jordan commented on CASSANDRA-7020:
If we change this at all, I think we should probably only change this in 3.0 or
even only in trunk. This is a pretty big behavior change.
> Incorrect result of query WHERE token(key) < -9223372036854775808 when using
> Murmur3Partitioner
> ---
>
> Key: CASSANDRA-7020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7020
> Project: Cassandra
> Issue Type: Bug
> Environment: cassandra 2.0.6-snapshot
>Reporter: Piotr Kołaczkowski
>Assignee: Marko Denda
> Fix For: 2.1.x
>
> Attachments: 7020.txt
>
>
> {noformat}
> cqlsh:test1> select * from test where token("key") < -9223372036854775807;
> (0 rows)
> cqlsh:test1> select * from test where token("key") < -9223372036854775808;
> key | value
> -+--
>5 | ee
> 10 |j
>1 |
>8 |
>2 | bbb
>4 | dd
>7 |
>6 | fff
>9 |
>3 |c
> {noformat}
> Expected: empty result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7020) Incorrect result of query WHERE token(key) < -9223372036854775808 when using Murmur3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14712585#comment-14712585
]
Piotr Kołaczkowski commented on CASSANDRA-7020:
---
+1
> Incorrect result of query WHERE token(key) < -9223372036854775808 when using
> Murmur3Partitioner
> ---
>
> Key: CASSANDRA-7020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7020
> Project: Cassandra
> Issue Type: Bug
> Environment: cassandra 2.0.6-snapshot
>Reporter: Piotr Kołaczkowski
>Assignee: Marko Denda
> Fix For: 2.0.x
>
> Attachments: 7020.txt
>
>
> {noformat}
> cqlsh:test1> select * from test where token("key") < -9223372036854775807;
> (0 rows)
> cqlsh:test1> select * from test where token("key") < -9223372036854775808;
> key | value
> -+--
>5 | ee
> 10 |j
>1 |
>8 |
>2 | bbb
>4 | dd
>7 |
>6 | fff
>9 |
>3 |c
> {noformat}
> Expected: empty result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7020) Incorrect result of query WHERE token(key) < -9223372036854775808 when using Murmur3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14712562#comment-14712562
]
Marko Denda commented on CASSANDRA-7020:
Hi Piotr,
I can't find any other case to reproduce the similar. Feel free to
report/raise a case if you notice something else otherwise can you give
+1 for this?
Kind regards,
Marko
> Incorrect result of query WHERE token(key) < -9223372036854775808 when using
> Murmur3Partitioner
> ---
>
> Key: CASSANDRA-7020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7020
> Project: Cassandra
> Issue Type: Bug
> Environment: cassandra 2.0.6-snapshot
>Reporter: Piotr Kołaczkowski
>Assignee: Marko Denda
> Fix For: 2.0.x
>
> Attachments: 7020.txt
>
>
> {noformat}
> cqlsh:test1> select * from test where token("key") < -9223372036854775807;
> (0 rows)
> cqlsh:test1> select * from test where token("key") < -9223372036854775808;
> key | value
> -+--
>5 | ee
> 10 |j
>1 |
>8 |
>2 | bbb
>4 | dd
>7 |
>6 | fff
>9 |
>3 |c
> {noformat}
> Expected: empty result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7020) Incorrect result of query WHERE token(key) < -9223372036854775808 when using Murmur3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14711852#comment-14711852
]
Piotr Kołaczkowski commented on CASSANDRA-7020:
---
"Note though that in the case where startToken or endToken is the minimum
token, then
this special case rule should not apply."
[~marcus_d] any thoughts why this special case was not applied before? The
patch looks good, but I wonder what else relied on returning everything when
startToken or endToken was minimum token.
> Incorrect result of query WHERE token(key) < -9223372036854775808 when using
> Murmur3Partitioner
> ---
>
> Key: CASSANDRA-7020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7020
> Project: Cassandra
> Issue Type: Bug
> Environment: cassandra 2.0.6-snapshot
>Reporter: Piotr Kołaczkowski
>Assignee: Marko Denda
> Fix For: 2.0.x
>
> Attachments: 7020.txt
>
>
> {noformat}
> cqlsh:test1> select * from test where token("key") < -9223372036854775807;
> (0 rows)
> cqlsh:test1> select * from test where token("key") < -9223372036854775808;
> key | value
> -+--
>5 | ee
> 10 |j
>1 |
>8 |
>2 | bbb
>4 | dd
>7 |
>6 | fff
>9 |
>3 |c
> {noformat}
> Expected: empty result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7020) Incorrect result of query WHERE token(key) < -9223372036854775808 when using Murmur3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14709499#comment-14709499
]
Jonathan Ellis commented on CASSANDRA-7020:
---
Piotr, can you review?
> Incorrect result of query WHERE token(key) < -9223372036854775808 when using
> Murmur3Partitioner
> ---
>
> Key: CASSANDRA-7020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7020
> Project: Cassandra
> Issue Type: Bug
> Environment: cassandra 2.0.6-snapshot
>Reporter: Piotr Kołaczkowski
>Assignee: Marko Denda
> Fix For: 2.0.x
>
> Attachments: 7020.txt
>
>
> {noformat}
> cqlsh:test1> select * from test where token("key") < -9223372036854775807;
> (0 rows)
> cqlsh:test1> select * from test where token("key") < -9223372036854775808;
> key | value
> -+--
>5 | ee
> 10 |j
>1 |
>8 |
>2 | bbb
>4 | dd
>7 |
>6 | fff
>9 |
>3 |c
> {noformat}
> Expected: empty result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7020) Incorrect result of query WHERE token(key) < -9223372036854775808 when using Murmur3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594578#comment-14594578
]
Marko Denda commented on CASSANDRA-7020:
Hi, patch is created for this issuse CASSANDRA-7020. Please review it
> Incorrect result of query WHERE token(key) < -9223372036854775808 when using
> Murmur3Partitioner
> ---
>
> Key: CASSANDRA-7020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7020
> Project: Cassandra
> Issue Type: Bug
> Environment: cassandra 2.0.6-snapshot
>Reporter: Piotr Kołaczkowski
>Assignee: Marko Denda
> Attachments: CASSANDRA-7020.patch
>
>
> {noformat}
> cqlsh:test1> select * from test where token("key") < -9223372036854775807;
> (0 rows)
> cqlsh:test1> select * from test where token("key") < -9223372036854775808;
> key | value
> -+--
>5 | ee
> 10 |j
>1 |
>8 |
>2 | bbb
>4 | dd
>7 |
>6 | fff
>9 |
>3 |c
> {noformat}
> Expected: empty result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7020) Incorrect result of query WHERE token(key) < -9223372036854775808 when using Murmur3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589575#comment-14589575
]
Anton commented on CASSANDRA-7020:
--
The same when equal.
{code}
cqlsh:test1> select * from test where token("key") = -9223372036854775808;
key | value
-+--
5 | ee
10 |j
1 |
8 |
2 | bbb
4 | dd
7 |
6 | fff
9 |
3 |c
{code}
Too bad.
> Incorrect result of query WHERE token(key) < -9223372036854775808 when using
> Murmur3Partitioner
> ---
>
> Key: CASSANDRA-7020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7020
> Project: Cassandra
> Issue Type: Bug
> Environment: cassandra 2.0.6-snapshot
>Reporter: Piotr Kołaczkowski
>Assignee: Marko Denda
>
> {noformat}
> cqlsh:test1> select * from test where token("key") < -9223372036854775807;
> (0 rows)
> cqlsh:test1> select * from test where token("key") < -9223372036854775808;
> key | value
> -+--
>5 | ee
> 10 |j
>1 |
>8 |
>2 | bbb
>4 | dd
>7 |
>6 | fff
>9 |
>3 |c
> {noformat}
> Expected: empty result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7020) Incorrect result of query WHERE token(key) < -9223372036854775808 when using Murmur3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133637#comment-14133637
]
Piotr Kołaczkowski commented on CASSANDRA-7020:
---
{quote}
-9223372036854775808 is min value for ssmtable scanned so putting it in where
clause of select statement behaves as select * from test{quote}
And this is illogical and surprising behavior because the tokens of the
returned rows do not satisfy the condition in the query. No token is ever
smaller than min token, therefore the only correct answer is empty row set here.
Nevertheless, if it were to wrap-around, it needs to wrap-around always
consistently, not just for the min token. So actually any query not restricting
the token range from both sides should return all rows.
Actually I like the idea of never wrapping around, because it doesn't make
token comparisons "special" and treats them just as any other integer
comparison.
> Incorrect result of query WHERE token(key) < -9223372036854775808 when using
> Murmur3Partitioner
> ---
>
> Key: CASSANDRA-7020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7020
> Project: Cassandra
> Issue Type: Bug
> Environment: cassandra 2.0.6-snapshot
>Reporter: Piotr Kołaczkowski
>Assignee: Marko Denda
>
> {noformat}
> cqlsh:test1> select * from test where token("key") < -9223372036854775807;
> (0 rows)
> cqlsh:test1> select * from test where token("key") < -9223372036854775808;
> key | value
> -+--
>5 | ee
> 10 |j
>1 |
>8 |
>2 | bbb
>4 | dd
>7 |
>6 | fff
>9 |
>3 |c
> {noformat}
> Expected: empty result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7020) Incorrect result of query WHERE token(key) < -9223372036854775808 when using Murmur3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133370#comment-14133370
]
Marko Denda commented on CASSANDRA-7020:
Hi,
I don't see reason why is this classified as error.
During execution of execute_cql3_query select * from test where token("key")
< -9223372036854775808 with tracing on we see following output:
key | value
-+-
5 | kkk
50 | rr
10 | bbb
25 | c
(4 rows)
Tracing session: 5e9ad790-3c4a-11e4-bc20-d7d1fe420dc4
activity
| timestamp| source| source_elapsed
-+--+---+
execute_cql3_query | 22:04:44,042 | 127.0.0.1 | 0
Parsing select * from test where token("key") <
-9223372036854775808; | 22:04:44,042 | 127.0.0.1 |121
Preparing statement | 22:04:44,043 | 127.0.0.1 |605
Determining
replicas to query | 22:04:44,043 | 127.0.0.1 |966
Executing seq scan across 1 sstables for (min(-9223372036854775808),
min(-9223372036854775808)] | 22:04:44,057 | 127.0.0.1 | 15008
Read 1 live and 0
tombstoned cells | 22:04:44,059 | 127.0.0.1 | 16339
Read 1 live and 0
tombstoned cells | 22:04:44,059 | 127.0.0.1 | 16583
Read 1 live and 0
tombstoned cells | 22:04:44,059 | 127.0.0.1 | 16816
Read 1 live and 0
tombstoned cells | 22:04:44,059 | 127.0.0.1 | 17009
Scanned 4
rows and matched 4 | 22:04:44,059 | 127.0.0.1 | 17202
Request complete | 22:04:44,059 | 127.0.0.1 | 17798
which is the same as select * from test;
cqlsh:sample> select * from test;
key | value
-+-
5 | kkk
50 | rr
10 | bbb
25 | c
(4 rows)
Tracing session: 16f5c710-3c4a-11e4-bc20-d7d1fe420dc4
activity
| timestamp| source| source_elapsed
-+--+---+
execute_cql3_query | 22:02:43,842 | 127.0.0.1 | 0
Parsing select * from
test LIMIT 1; | 22:02:43,842 | 127.0.0.1 |115
Preparing statement | 22:02:43,843 | 127.0.0.1 |468
Determining
replicas to query | 22:02:43,843 | 127.0.0.1 |843
Executing seq scan across 1 sstables for [min(-9223372036854775808),
min(-9223372036854775808)] | 22:02:43,861 | 127.0.0.1 | 19150
Seeking to partition
beginning in data file | 22:02:43,862 | 127.0.0.1 | 19957
Read 1 live and 0
tombstoned cells | 22:02:43,863 | 127.0.0.1 | 20425
Seeking to partition
beginning in data file | 22:02:43,863 | 127.0.0.1 | 20574
Read 1 live and 0
tombstoned cells | 22:02:43,863 | 127.0.0.1 | 20741
Seeking to partition
beginning in data file | 22:02:43,863 | 127.0.0.1 | 20869
Read 1 live and 0
tombstoned cells | 22:02:43,863 | 127.0.0.1 | 21033
Seeking to partition
beginning in data file | 22:02:43,863 | 127.0.0.1 | 21126
Read 1 live and 0
tombstoned cells | 22:02:43,864 | 127.0.0.1 | 21287
Scanned 4
rows and matched 4 | 22:02:43,864 | 127.0.0.1 | 21489
