[
https://issues.apache.org/jira/browse/TINKERPOP-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15715792#comment-15715792
]
Kevin Gallardo commented on TINKERPOP-1565:
-------------------------------------------
Here's my thoughts on a more broader angle then, I do not disagree with the
idea of selecting which kind of serialization you want to have, in order to
allow more possibilities wrt to attachment, or lightness, although I would
like to keep in sight that the more complex and dynamic the GraphSON format
will be, the more complex it will be to deserialize it and consequently more
complex to implement new GLVs. If you need to handle 4 different *combinations*
of formats (like each kind of element can have a different configuration of
detachment) instead of a constant one, it might get frustrating. GraphSON*2*
was introduced not only for the types, but also because GraphSON was too
inconsistent. Going back to a format where there can be a field "edge" in a
"g:Property" or that field could disappear to let place to another
"vertexProperty" for which the format is completely different, or the field
could simply disappear, or a field named "properties" that can have 2 different
schemas in the same enclosing entity, does seem to make things become more
inconsistent again.
I understand some times the server has to serialize more data to allow
reattachment to the parent element or Graph, however I believe that the
additional information that could be sent by the server should not modify how
the deserialization executes. I'd be advocating for a format that stays
constant but can potentially add detachment information, and in case that info
is sent by the server, it gets exposed via a extra method such as
{{Element.getAttachmentInfo()}} that the deserializer has conveniently filled
first via a "attachInfo" fields in the JSON. Then the client would be able to
do whatever it wants with that, but the deserializer does not do it itself,
because it hasn't got enough knowledge of the context to do so. Concerning
properties (Vertices'/Edges or VPs'), the field would either be empty, or
filled, in a consistent manner (and for me more consistent would mean it would
be typed as either "g:Property" or "g:VertexProperty" -> which both would have
a consistent schema).
{code}{ @type:”g:Vertex", @detach:”reference", @value: { id:1 } }{code}
Note: As explained above the "@detach" would be part of the "@value" and should
not alter the type format itself because this is not relevant information at
this stage of the deserialization. The type system is domain agnostic and
simply allows a Type to be associated with a value.
> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and
> reducing verbosity
> ----------------------------------------------------------------------------------------------
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
> Affects Versions: 3.2.3
> Reporter: Marko A. Rodriguez
> Assignee: Marko A. Rodriguez
> Labels: breaking
>
> GraphSON 2.0 has some issues that should be recified for its "official
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding
> in {{VertexProperty}}.
> Edge -->
> {code}
> properties : {
> key : "aKey",
> value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
> key : "aKey",
> value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and
> is typicaly used to ensure a data rich result set. {{ReferenceElements}}
> contain only the necessary information for attachment. I think we can support
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired,
> we only send/recv information that is needed for the particular
> computatation. E.g. as dictated by {{HaltedTraverserStrategy}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
