[jira] [Updated] (TINKERPOP-1427) GraphSON 2.0 needs collection types and consistent number typing.

["Marko A. Rodriguez (JIRA)" <ji...@apache.org>]

     [ 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)