[
https://issues.apache.org/jira/browse/GEODE-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Tzolov updated GEODE-3971:
------------------------------------
Description:
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}
{ "_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}
was:
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}
> 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}
> { "_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)
