[
https://issues.apache.org/jira/browse/CASSANDRA-12923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673503#comment-15673503
]
Branimir Lambov commented on CASSANDRA-12923:
---------------------------------------------
I'm quite happy with only documenting it somewhere visible (e.g. in the [CQL
data type definition|http://cassandra.apache.org/doc/latest/cql/types.html]).
The problem is easily solvable on the user or driver side (applying
normalization there) but only if people are aware of it before data is poured
in the system.
> Decimal type has inconsistent equality semantics when used in partition key
> ---------------------------------------------------------------------------
>
> Key: CASSANDRA-12923
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12923
> Project: Cassandra
> Issue Type: Bug
> Reporter: Branimir Lambov
>
> Unlike {{double}} or {{float}}, for {{decimal}} used as primary key in
> Cassandra we have that {{3 != 3.0}} even though {{3 <= 3.0}} and {{3 >= 3.0}}:
> {code}
> cqlsh:keyspace1> create table testdec (key decimal primary key, value int);
> cqlsh:keyspace1> insert into testdec (key, value) values (3.0, 3);
> cqlsh:keyspace1> select * from testdec;
> key | value
> ------+-------
> 3.0 | 3
> (1 rows)
> cqlsh:keyspace1> select * from testdec where key = 3;
> key | value
> -----+-------
> (0 rows)
> cqlsh:keyspace1> select * from testdec where key = 3.0;
> key | value
> -----+-------
> 3.0 | 3
> (1 rows)
> cqlsh:keyspace1> select * from testdec where key >= 3 and key <= 3 ALLOW
> FILTERING;
> key | value
> -----+-------
> 3.0 | 3
> (1 rows)
> {code}
> The reason for this is that we use the key's bytes (as produced by
> {{BigDecimal}}) to form the token:
> {code}
> cqlsh:keyspace1> select * from testdec where token(key) = token(3);
> key | value
> -----+-------
> (0 rows)
> cqlsh:keyspace1> select * from testdec where token(key) = token(3.0);
> key | value
> -----+-------
> 3.0 | 3
> (1 rows)
> {code}
> as well as to check key matches in
> [{{BigTableReader.getPosition}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/big/BigTableReader.java#L217].
> The solution is to always store a canonical form of each key. In this case,
> such a value that the decimal's _unscaled value_ is not divisible by 10.
> This problem may be affecting other types as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)