[
https://issues.apache.org/jira/browse/TINKERPOP-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15703096#comment-15703096
]
Kevin Gallardo edited comment on TINKERPOP-1565 at 11/28/16 9:30 PM:
---------------------------------------------------------------------
"I think we should treat each element type individually"
So that's another option, as long as all do the same consistently, but why
would we do that? Is it only for the size of the payload? The way I see it I
find it useful to rely on that "cascade" because: 1. we have to rely on it
anyway for the other "non Graph structural" types - 2. it simplifies the
deserialization logic - 3. it reflects directly what the actual objects are in
the actual implementation of the serialized objects - 4. it may cause
inconsistencies otherwise, considering one would change one day the code of the
VertexPropertyDeserializer, but do not in the VertexDeserializer, and would
need to do it there as well, so all in all, it's a code maintenance
inconvenience.
The docs say that StarGraph serialization is a format made for size efficiency,
which we had said was not to be a concern with the GraphSON2 standard
serialization. If that's not the case then fine but there is then a lot of over
things we can do to make the GraphSON2 protocol more size efficient, but that
was clearly not stated as a goal initially. For example types names are encoded
with a descriptive name as well as the "@type" and "@value" identifiers, where
all could be smaller but it was decided that we wanted to be more descriptive
here, as other future protocols can be made and be much more size efficient.
was (Author: newkek):
"I think we should treat each element type individually"
So that's another option, as long as all do the same consistently, but why
would we do that? Is it only for the size of the payload? The way I see it I
find it useful to rely on that "cascade" because: 1. we have to rely on it
anyway for the other "non Graph structural" types - 2. it simplifies the
deserialization logic - 3. it reflects directly what the actual objects are in
the actual implementation of the serialized objects - 4. it may cause
inconsistencies otherwise, considering one would change one day the code of the
VertexPropertyDeserializer, but do not in the VertexDeserializer, and would
need to do it there as well, so all in all, it's a code maintenance
inconvenience.
The docs say that StarGraph is a format made for size efficiency, which we had
said was not to be a concern with the GraphSON2 standard serialization. If
that's not the case then fine but there is then a lot of over things we can do
to make the GraphSON2 protocol more size efficient, but that was clearly not
stated as a goal initially. For example types names are encoded with a
descriptive name as well as the "@type" and "@value" identifiers, where all
could be smaller but it was decided that we wanted to be more descriptive here,
as other future protocols can be made and be much more size efficient.
> 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)
