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

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Component/s: rest (dev)
• Assignee: Unassigned
• Reporter: Christian Tzolov
• Created: 13/Nov/17 08:46
• Updated: 20/Apr/18 03:58

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:

{ "_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" }

It will result in 3 different java number types being used by Geode:

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

This inconsistency alone is bad enough but it also causes aggregation functions to fail:

gfsh>query --query="SELECT MAX(pop) from /geodeRegion"
Message : java.lang.Integer cannot be cast to java.lang.Byte
Result : false