[
https://issues.apache.org/jira/browse/TINKERPOP-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15691560#comment-15691560
]
Kevin Gallardo commented on TINKERPOP-1565:
-------------------------------------------
h5. Reference and Detached Elements:
I believe that this can be nicely handled by having a GraphSONModule added to
the GraphSONMapper, that replaces all the current serializers and
deserializers, with lighter ones, that serializes *all* the Elements as
Reference Elements, and deserializes them accordingly to Reference Elements.
The GraphSON2Mapper is dynamic enough to allow to override the serializers and
deserializers for already existing types like the Graph structure types, so
you'd have all the "g:Vertex"/"g:VertexProperty" types mapped to
Vertex/VertexProperty but the implem would be Detached Elements instead of the
current Detached more heavy ones. But it sounds weird to me if we had in a same
response, different formats for the same "g:" type.
h5. Consistency with Properties
It sounds reasonable that all the classes that derive from Element, have their
properties serialized in the same format, for consistency. Since we cannot go
around having Vertices' VertexProperties being serialized with their types,
then the other Elements (VertexProperty's Properties and Edge Properties)
should follow the same path.
h5. Attaching deserialized elements
I understand the need of the parent info to reattach. However, the comment I
made was on the way it was done that could lead to problems. Assuming the code
in the PR was *creating a new* Vertex object when deserializing a
VertexProperty, based on the Vertex ID info there was in the JSON. So when a
VertexProperty is serialized on its own, that's fine. But when a VertexProperty
is serialized as part of its parent Vertex (so the JSON is "v + vp1 + vp2 +
...."), then creating a new Vertex object when deserializing the VertexProperty
means that the actual parent object of the VP, and what the VP thinks its
parent is, are not the same (Java)objects
({{v.properties('name').next().element() != v}}). That's why I introduced that
mechanism in Jackson to indicate to the VP deserializer for example, if the VP
to deserialize is on its own or if it's been serialized with its parent. Hope
that's clearer
> 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
> Labels: breaking
> Fix For: 3.2.3
>
>
> 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)
