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