Marko A. Rodriguez created TINKERPOP-1427:
---------------------------------------------
Summary: GraphSON 2.0 needs collection types and consistent number
typing.
Key: TINKERPOP-1427
URL: https://issues.apache.org/jira/browse/TINKERPOP-1427
Project: TinkerPop
Issue Type: Improvement
Components: io
Affects Versions: 3.2.1
Reporter: Marko A. Rodriguez
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:
{code}
g:Map
g:List
g:Set
{code}
Note that all of these would just be JSON lists:
{code}
{@type:"g:Map", @value:[key1,value1,key2,value2,key3,value3,...]}
{@type:"g:List", @value:[value1, value2, value3,...]}
{@type:"g:Set", @value:[value1, value2, value3,...]}
{code}
---
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.
{code}
g:Int32 -> g:Integer
g:Int64 -> g:Long
g:Double -> g:Double (no change)
g:Float -> g:Float (no change)
{code}
If we want to be consistent either do the above or do the below, though I think
the above is cleaner.
{code}
g:Int32 -> g:Int32
g:Int64 -> g:Int64
g:Float -> g:Float32
g:Double -> g:Float64
{code}
Again, using programming lexicon vs. physical machine lexicon is best and thus,
just gut "int32" and "int64."
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
