Hi,
However, in general we just need an “object mapper pattern.” For instance:
For any JSON object { } that has a @type field, the @type value maps to a
deserializer. Thus, while we need to be able to serialize/deserialize the
standard Vertex/Edge/VertexProperty/etc. the representation should be
generalized to support any registered @type.
Java GraphSON serializer/deserializer registration:
https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONModule.java#L129-L147
<https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONModule.java#L129-L147>
Python GraphSON serializer registration:
https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-python/src/main/jython/gremlin_python/process/graphson.py#L122-L127
<https://github.com/apache/tinkerpop/blob/TINKERPOP-1278/gremlin-python/src/main/jython/gremlin_python/process/graphson.py#L122-L127>
People can register more @types as needed for their graph processor’s type
system.
Marko.
http://markorodriguez.com
> On Jul 19, 2016, at 12:55 PM, Marko Rodriguez <okramma...@gmail.com> wrote:
>
> We need:
>
> Graph
> Element
> Vertex
> Edge
> VertexProperty
> Property
> Path
> TraversalExplanation
> TraversalMetrics
> Traversal (i.e. Bytecode)
> Traverser (object + bulk at minimum)
>
> Marko.
>
> http://markorodriguez.com
>
>
>
>> On Jul 19, 2016, at 12:45 PM, Robert Dale <robd...@gmail.com> wrote:
>>
>> There's also Path that can be returned from a query. It looks like
>> GraphSON 1.0 handles this today in the REST API but it's not typed as
>> a path.
>>
>> On Tue, Jul 19, 2016 at 2:14 PM, gallardo.kev...@gmail.com
>> <gallardo.kev...@gmail.com> wrote:
>>>
>>>
>>> On 2016-07-19 18:02 (+0100), Robert Dale <robd...@gmail.com> wrote:
>>>> - It seems redundant to nest a vertex or edge inside a type-value
>>>> object and is inconsistent with a VertexProperty.
>>>> - VertexProperty and (edge) Property are implicit types. I don't know
>>>> if this is ok. Could they ever be used outside of their parents where
>>>> they would need to be typed?
>>>
>>> I agree with the VertexProperty remark. That's one last question I wanted
>>> to solve, if we go for typing Vertex and edges, do we include others? The
>>> full list I see then is : vertex/edge/vertexproperty/property/graph.
>>>
>>> However I am not sure how useful it is to have more than Vertex and Edge.
>>> As, when deserializing a Vertex for example, there's no question as to what
>>> is in the "properties" field of the Vertex, there are necessarily only
>>> VertexProperties. However looking at the API, it seems like it is supported
>>> to write only a VertexProperty if one wants to (see
>>> GraphWriter.writeVertexProperty()), so in that case, to me it makes sense
>>> to add the types for the elements of the list I described above. @stephen
>>> any thoughts about that ?
>>>
>>>> - Edges:
>>>> - is in/outVLabel new? Couldn't find it in the API or any examples of this.
>>>> - why not make inV/outV have proper vertices with labels (to satisfy
>>>> the case previous case) instead of just IDs? This would also be more
>>>> consistent with the API.
>>>
>>> I haven't touched that part, it was in the format before. I believe this is
>>> a question for Stephen.
>>>
>>>>
>>>> Otherwise looks good!
>>>
>>> Thanks for the feedback.
>>>>
>>>> On Tue, Jul 19, 2016 at 12:05 PM, gallardo.kev...@gmail.com
>>>> <gallardo.kev...@gmail.com> wrote:
>>>>>
>>>>>
>>>>> On 2016-07-15 16:25 (+0100),
>>>>> "gallardo.kev...@gmail.com"<gallardo.kev...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 2016-07-09 16:48 (+0100), Stephen Mallette <spmalle...@gmail.com>
>>>>>> wrote:
>>>>>>> With all the work on GLVs and the recent work on GraphSON 2.0, I think
>>>>>>> it's
>>>>>>> important that we have a solid, efficient, programming language neutral,
>>>>>>> lossless serialization format. Right now that format is GraphSON and it
>>>>>>> works for that purpose (ever more so with 2.0). Given some discussion
>>>>>>> on
>>>>>>> the GraphSON 2.0 PR driven a bit by Robert Dale:
>>>>>>>
>>>>>>> https://github.com/apache/tinkerpop/pull/351#issuecomment-231157389
>>>>>>>
>>>>>>> I wonder if we shouldn't consider another IO format that has Gremlin
>>>>>>> Server/GLVs in mind. At this point I'm not suggesting anything specific
>>>>>>> -
>>>>>>> I'm just hanging the idea out for further discussion and brain storming.
>>>>>>> Thoughts?
>>>>>>>
>>>>>>
>>>>>> Hey, so I'm trying to gather all infos we have here in order to prepare
>>>>>> to move forward with the implem of GraphSON 2.0, here's what I come up
>>>>>> with :
>>>>>>
>>>>>> Things we have :
>>>>>> - Type format.
>>>>>> - The structure in Jackson to implement our own type format.
>>>>>> - All non native Graph types are typed (except the domain specific
>>>>>> types).
>>>>>>
>>>>>> New things we need :
>>>>>> - Types for domain specific objects.
>>>>>> - Types for all numeric values.
>>>>>> - Don't serialize empty fields (outV and stuff).
>>>>>>
>>>>>> Things we consider changing :
>>>>>> - Type IDs convention. Before : Java simple class names. Now : starts
>>>>>> with a "domain" like "gremlin" followed by the "type name", which is a
>>>>>> lowercased type name (like "uuid", or "float", or "vertex"). Example :
>>>>>> "gremlin:uuid".
>>>>>> - Type format ?
>>>>>>
>>>>>> Am I missing something ?
>>>>>>
>>>>> Hey,
>>>>>
>>>>> So I've made a few changes in the code from the original GraphSON 2.0,
>>>>> with the objectives described above, the code is still messy but I just
>>>>> thought I'd share some samples to start getting into the work and gather
>>>>> some feedback.
>>>>>
>>>>> In the example I've created a TinkerGraph with 2 vertices connected by an
>>>>> edge. The graph is serialized as a TinkerGraph.
>>>>> The samples are there :
>>>>> https://gist.github.com/newkek/97da94342bc32e571cf4a0ba1018df60
>>>>>
>>>>> Any feedback appreciated.
>>>>
>>>>
>>>>
>>>> --
>>>> Robert Dale
>>>>
>>
>>
>>
>> --
>> Robert Dale
>
