[
https://issues.apache.org/jira/browse/TINKERPOP-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko A. Rodriguez updated TINKERPOP-1427:
------------------------------------------
Labels: breaking (was: )
> 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
> Labels: breaking
>
> 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)
