Description
Before 3.3.0, we need to get the story around collections straight. Currently we are relying on JSON collections to represent our collections, but this isn't always sound – e.g. JSON maps can only have string keys.
Thus, we need:
g:Map g:List g:Set
Note that all of these would just be JSON lists:
{@type:"g:Map", @value:[key1,value1,key2,value2,key3,value3,...]}
{@type:"g:List", @value:[value1, value2, value3,...]}
{@type:"g:Set", @value:[value1, value2, value3,...]}
—
Next, these data structures are exactly what play into aggregateTo in sideEffects for RemoteConnection. Thus, we should use these types and, as well, get rid of none as the aggregate would be a real type like g:Int32.
Also, I think we should abandon this hybrid physical machine naming convention and programming language type convention.
g:Int32 -> g:Integer g:Int64 -> g:Long g:Double -> g:Double (no change) g:Float -> g:Float (no change)
If we want to be consistent either do the above or do the below, though I think the above is cleaner.
g:Int32 -> g:Int32 g:Int64 -> g:Int64 g:Float -> g:Float32 g:Double -> g:Float64
Again, using programming lexicon vs. physical machine lexicon is best and thus, just gut "int32" and "int64."
Attachments
Issue Links
- is duplicated by
-
TINKERPOP-1658 Graphson2 map keys are serialised as strings
-
- Closed
-
- links to
