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

["Dylan Millikin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TINKERPOP-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15464632#comment-15464632 ] 

Dylan Millikin edited comment on TINKERPOP-1427 at 9/5/16 9:51 AM:
-------------------------------------------------------------------

The problem though is that typing will be done on the underlying graph layers so we can't just handle "numbers" or we will run into conflicts (2 <> 2L). Which is why we went with the current {{int32}}/{{int64}}.

Also I agree with changing things around for maps. We will need to keep {{Tree}} serialization in mind though. As it would produce structurally different results depending on whether or not typing is turned on.
Tree is already a JSON {{Map<Object, Object>}} serialization in GRAPHSON1


was (Author: dmill):
The problem though is that typing will be done on the underlying graph layers so we can't just handle "numbers" or we will run into conflicts (2 <> 2L). Which is why we went with the current int32/int64.

Also I agree with changing things around for maps. We will need to keep {{Tree}} serialization in mind though. As it would produce structurally different results depending on whether or not typing is turned on.
Tree is already a JSON Map<Object, Object> serialization in GRAPHSON1

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