[
https://issues.apache.org/jira/browse/TINKERPOP-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15466882#comment-15466882
]
Dylan Millikin commented on TINKERPOP-1427:
-------------------------------------------
I hear you, trust me. I'm just pointing out some potential conflicts. I'm not
sure if this could be another but what of the Property typing for some DBs
(like Titan). If you have a schema expecting Long are we going to have
conflicts?
> 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)
