I haven't yet had a chance to fully think this change through, but I think the idea would be to produce a new version of GraphSON and keep the old version around for backward compatibility. It would also only be a breaking change for type embedded GraphSON, which i would guess the minority are using right now as its verbosity and dependence on java types makes it borderline unusable off the JVM. I think this is a nice proposal because it tries to make embedded types something that could actually be usable in a more general fashion across different programming languages. Anyway, the key point is that we would want to try to still support the old version of type-embedded graphson in addition to what kevin has proposed.
On Fri, Apr 1, 2016 at 9:11 AM, Dylan Millikin <dylan.milli...@gmail.com> wrote: > I also thought about this when I tried to set this serializer up with the > php driver. This is quite a breaking change though. > > On Thu, Mar 31, 2016 at 1:33 PM, Kevin Gallardo < > kevin.galla...@datastax.com > > wrote: > > > Hi, > > > > > > By working closely with Tinkerpop I have been interacting quite a bit > with > > the GraphSON format and I have come up with the need of using the > > "embedTypes" option of the GraphSON Mapper to get more insight of the > types > > of the data I was transferring through the GraphSON payload. > > > > By default vertices, edges, having properties that have another type than > > the natively supported types in the JSON format are encoded as their > String > > representation. Meaning that a Vertex property being a UUID will look > like > > "24B7DED2-F72A-11E5-815D-79DF61FECC63" which, for the user consuming the > > JSON produced by the GraphSONWriter, will not be distinguishable from > being > > a String or a UUID. That is usually why you need to activate the type > > embedding of GraphSON. Documentation about the current output of GraphSON > > typing : > > > > > http://tinkerpop.apache.org/docs/3.1.1-incubating/reference/#graphson-reader-writer > > > > However, right now, embedding types with GraphSON comes with a few trade > > offs : > > > > - It is very verbose, mostly because Arrays and Maps types are > embedded. > > But Arrays and Maps are natively supported in JSON, and other native > > types > > like Strings or booleans do not appear typed, so these types should > > logically also be excluded, since natively supported in JSON. > > - It is not consistent, if the type is to be embedded in a JSON > Object, > > it will come as a JSON Object's element, a key-value pair {"@class" : > > "java.util.HashMap", ... }, whereas if the type is to be embedded in a > > JSON > > Array, it will be embedded in "best-effort" and put as a simple value > > that > > will be ["java.util.HashMap", ... ], hence it makes it difficult to > > automatically parse typed results. > > - It is Java centric. > > > > I'd like to propose a format to encapsulate values format, that would > > address the points mentioned above, in which the main idea being that > > whenever a type needs to be embedded, the value itself and the type would > > be encapsulated in an Array, and the first element is a JSON Object > > containing only the key/value pair {"@class": "TypeName"}, the second > > element being the value. > > > > A Short integer value encoded would change from : > > > > 2 > > > > *untyped, to : > > > > [{"@class":"Short"}, 2] > > > > with the type. > > > > It's just an example, but I thought this format would be robust enough. > And > > properties or other elements for which types are natively supported in > JSON > > would not need the additional metadata about their types, like it is now > > with GraphSON. I have a working prototype for this. > > > > Taking the Tinkerpop's doc example of GraphSON embedded types and > applying > > the proposed changes : > > > > ----------------------------- > > > > { > > "@class":"java.util.HashMap", > > "id":1, > > "label":"person", > > "outE":{ > > "@class":"java.util.HashMap", > > "created":[ > > "java.util.ArrayList", > > [ > > { > > "@class":"java.util.HashMap", > > "id":9, > > "inV":3, > > "properties":{ > > "@class":"java.util.HashMap", > > "weight":0.4 > > } > > } > > ] > > ], > > "knows":[ > > "java.util.ArrayList", > > [ > > { > > "@class":"java.util.HashMap", > > "id":7, > > "inV":2, > > "properties":{ > > "@class":"java.util.HashMap", > > "weight":0.5 > > } > > }, > > { > > "@class":"java.util.HashMap", > > "id":8, > > "inV":4, > > "properties":{ > > "@class":"java.util.HashMap", > > "weight":1 > > } > > } > > ] > > ] > > }, > > "properties":{ > > "@class":"java.util.HashMap", > > "name":[ > > "java.util.ArrayList", > > [ > > { > > "@class":"java.util.HashMap", > > "id":[ > > "java.lang.Long", > > 0 > > ], > > "value":"marko" > > } > > ] > > ], > > "age":[ > > "java.util.ArrayList", > > [ > > { > > "@class":"java.util.HashMap", > > "id":[ > > "java.lang.Long", > > 1 > > ], > > "value":29 > > } > > ] > > ] > > } > > } > > > > > > -------------------------------------------------------------- > > > > With the changes : > > > > { > > "id":1, > > "label":"person", > > "outE":{ > > "created":[ > > { > > "id":9, > > "inV":3, > > "properties":{ > > "weight":0.4 > > } > > } > > ], > > "knows":[ > > { > > "id":7, > > "inV":2, > > "properties":{ > > "weight":0.5 > > } > > }, > > { > > "id":8, > > "inV":4, > > "properties":{ > > "weight":1 > > } > > } > > ] > > }, > > "properties":{ > > "name":[ > > { > > "id":[ > > {"@class":"Long"}, > > 0 > > ], > > "value":"marko" > > } > > ], > > "age":[ > > { > > "id":[ > > {"@class":"Long"}, > > 1 > > ], > > "value":29 > > } > > ] > > } > > } > > > > ---------------------------------------------------- > > > > Open to suggestions and your feedback. > > > > > > > > Cheers! > > > > -- > > Kévin Gallardo. > > kgdo.me > > >
