ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Paschenko (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (IGNITE-5818) SQL: query with condition on affinity column works incorrect in some cases.
Date Tue, 25 Jul 2017 10:26:00 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-5818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16099828#comment-16099828
] 

Alexander Paschenko edited comment on IGNITE-5818 at 7/25/17 10:25 AM:
-----------------------------------------------------------------------

[~amashenkov]
In fact, it *does* work correctly.

Things go like this in this case:

1. {{new BigDecimal(8.3)}}, {{new BigDecimal("8.3")}} and {{new BigDecimal("8.30")}} are *all*
different objects (i.e. have different hash codes and thus obviously are not "equal" in Java
terms) - see [1], [2].

2. Ignite's affinity machinery relies on hash codes.

3. H2's {{BigDecimal}} comparison relies on {{compareTo}}, not on {{equals}}, therefore objects
that are not equal from Java objects' standpoint *may* be equal from the point of {{BigDecimal}}'s
inner representation - that's why your check passes when {{ID}} column is compared, as in
this case no partitions prediction is done because {{_key}} column is not involved, and all
nodes (or, as in your test, the only node) receive data request.

Per p. 1 and 2, the test fails absolutely right, *it should not pass* because the objects
are *different*. To avoid confusion here, the best is just to avoid messing with {{_key}}
column.

Another workaround would be to avoid {{String}} constructor and pass {{double}} instead -
probably parsed from a {{String}}, but you'd have to be careful about precision in this case
- please see [1] and [2] again.

Probably we should make that partitions detection optimization optional and turnable off.
I'd like to hear [~vozerov] on this.

[1] https://stackoverflow.com/questions/3693014/bigdecimal-from-double-incorrect-value
[2] https://stackoverflow.com/questions/12395281/convert-double-to-bigdecimal-and-set-bigdecimal-precision


was (Author: al.psc):
[~amashenkov]
In fact, it *does* work correctly.

Things go like this in this case:

1. {{new BigDecimal(8.3)}}, {{new BigDecimal("8.3")}} and {{new BigDecimal("8.30")}} are *all*
different objects (i.e. have different hash codes and thus obviously are not "equal" in Java
terms) - see [1], [2].

2. Ignite's affinity machinery relies on hash codes.

3. H2's {{BigDecimal}} comparison relies on {{compareTo}}, not on {{equals}}, therefore objects
that are not equal from Java objects' standpoint *may* be equal from the point of {{BigDecimal}}'s
inner representation - that's why your check passes when {{ID}} column is compared, as in
this case no partitions prediction is done because {{_key}} column is not involved, and all
nodes (or, as in your test, the only node) receive data request.

Per p. 1 and 2, the test fails absolutely right, *it should not pass* because the objects
are *different*. To avoid confusion here, the best is just to avoid messing with {{_key}}
column.

Another workaround would be to avoid {{String}} constructor and pass {{double}} instead -
probably parsed from a {{String}}.

Probably we should make that partitions detection optimization optional and turnable off.
I'd like to hear [~vozerov] on this.

[1] https://stackoverflow.com/questions/3693014/bigdecimal-from-double-incorrect-value
[2] https://stackoverflow.com/questions/12395281/convert-double-to-bigdecimal-and-set-bigdecimal-precision

> SQL: query with condition on affinity column works incorrect in some cases.
> ---------------------------------------------------------------------------
>
>                 Key: IGNITE-5818
>                 URL: https://issues.apache.org/jira/browse/IGNITE-5818
>             Project: Ignite
>          Issue Type: Bug
>          Components: sql
>    Affects Versions: 2.1
>            Reporter: Andrew Mashenkov
>             Fix For: 2.2
>
>         Attachments: DecimalKeyTest.java
>
>
> Looks like query optimization IGNITE-4509 [1] makes some kind of keys to be compared
incorrectly.
> E.g. Decimal key. PFA repro.
> [1] https://issues.apache.org/jira/browse/IGNITE-4509



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message