Hello fellow Igniters,

We have troubles with BigDecimal and BigInteger types used as cache keys
and then referenced in SQL.

As far as I see, our implementation of SQL considers BigDecimal to be SQL's
DECIMAL type.
But semantics of BigDecimal are different. BigDecimal("4.2") not equals to
BigDecimal("4.20"), but people assume they can find a row with 4.20 DECIMAL
key by searching for 4.2. Which doesn't work.

On the side note, does anybody have seen what SQL standard has to say on
the issue? How should DECIMAL type work? I expect we've got to have our own
DECIMAL type implementation completely divorced from BigDecimal, but I have
no idea about migration path.

BigInteger suffers from the opposite problem. Ignite doesn't treat it as
DECIMAL and just stores it as Object. But H2 indexing considers it a number
type and converts it to a ValueNumber when it gets passed as a parameter,
with subsequent comparisons on it failing, as outlined in
https://issues.apache.org/jira/browse/IGNITE-5855

We could change our code to treat BigInteger in keys the same way
BigDecimals are treated, but this would most likely introduce an
incompatibility.

Maybe we should disable having BigDecimal & BigInteger as cache keys at
all? Check for any of those in CacheConfiguration.setIndexedTypes() perhaps
and throw and exception urging user to change those to String. This will
save people some fruitless effort and leave a door to introducing more
sophisticated number type for cache keys later on.

WDYT?


-- 
Ilya Kasnacheev

Reply via email to