[jira] [Updated] (GEODE-3971) JSON/REST API yields inconsistent Number types and breaks Aggregation functions

["Anthony Baker (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anthony Baker updated GEODE-3971:
---------------------------------
    Component/s: rest (dev)

> 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
>          Components: rest (dev)
>            Reporter: Christian Tzolov
>            Priority: Major
>
> 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
(v7.6.3#76005)