Christian Tzolov created GEODE-3971:
---------------------------------------
Summary: JSON/REST API yields inconsistent Number types and breaks
Aggregation functions
Key: GEODE-3971
URL: https://issues.apache.org/jira/browse/GEODE-3971
Project: Geode
Issue Type: Bug
Reporter: Christian Tzolov
If you POST through the REST API, JSON documents with numeric field, chances
are that Geode will use different Java types to represent those number fields
(e.g from Byte to Long)
For example if you post the following tree JSON documents with different pop
field values:
{code:json}
{ "_id" : "27821", "city" : "EDWARD", "loc" : [ -76.87938800000001, 35.323588
], "pop" : 122, "state" : "NC" }
{ "_id" : "75227", "city" : "DALLAS", "loc" : [ -96.68358600000001, 32.767226
], "pop" : 39631, "state" : "TX" }
{ "_id" : "12461", "city" : "KRUMVILLE", "loc" : [ -74.246954, 41.895906 ],
"pop" : 1423, "state" : "NY" }
{code}
It will result in 3 different java number types being used by Geode:
{panel}
gfsh>query --query="SELECT pop.getClass().getCanonicalName(), count(*) as cnt
FROM /geodeRegion group by(pop.getClass().getCanonicalName())"
getCanonicalName | cnt
----------------- | -----
java.lang.Integer | 1
java.lang.Byte | 1
java.lang.Short | 1
{panel}
This inconsistency alone is bad enough but it also causes aggregation functions
to fail:
{panel}
gfsh>query --query="SELECT MAX(pop) from /geodeRegion"
Message : java.lang.Integer cannot be cast to java.lang.Byte
Result : false
{panel}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
