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