Re: Troubles with BigDecimal and BigInteger - maybe disable entirely?

[Ilya Kasnacheev]

Hello Andrey.

I'm not sure that BigDecimal makes for a passable SQL DECIMAL. Somebody
have to look at the standard sooner or later.

BigDecimal works as values as well, and BigInteger don't work, too.

I've created this remedy pull request and now am waiting for tests:
https://github.com/apache/ignite/pull/2512/commits/177be6475e7aee6fc0f04a010406bd57fb1da2ce
Also fixes BigIntever values.

The problem that in H2, there's special handling for BigInteger in DataType
class (which is used in statements) but not in Value class (which is used
in querying).

-- 
Ilya Kasnacheev

2017-08-29 19:07 GMT+03:00 Andrey Mashenkov :

> Ilya,
>
> 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.kasnach...@gmail.com>
> wrote:
>
> > 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
> >
>
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>

Re: Troubles with BigDecimal and BigInteger - maybe disable entirely?

[Andrey Mashenkov]

Ilya,

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 
wrote:

> 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
>



-- 
Best regards,
Andrey V. Mashenkov