ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Mashenkov <andrey.mashen...@gmail.com>
Subject Re: Troubles with BigDecimal and BigInteger - maybe disable entirely?
Date Tue, 29 Aug 2017 16:07:50 GMT

Ignite doesn't support scale\precision constrains for Decimal type,
so H2 treat them as Decimals with highest precision.

It is different issue as BigDecimal keys works, but with limitation.
However, BigInteger keys looks like doesn't work at all.

Disable having BigDecimal & BigInteger doesn't look like a solution for me.

What about using BigDecimal and BigInteger as values? Will SQL queries with
condition on these values work?

On Tue, Aug 29, 2017 at 6:45 PM, Ilya Kasnacheev <ilya.kasnacheev@gmail.com>

> 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.
> --
> Ilya Kasnacheev

Best regards,
Andrey V. Mashenkov

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message