[jira] [Commented] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity

["Marko A. Rodriguez (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TINKERPOP-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15713071#comment-15713071 ] 

Marko A. Rodriguez commented on TINKERPOP-1565:
-----------------------------------------------

Here is an idea that I had with [~pietermartin-tinkerpop] on gremlin-users.

----

Then I think we need to get smart about “what data?” We sort of already do with {{HaltedTraverserStrategy}} but this is really specific to internal computing and GremlinServer. We could go deeper into this path with:

{code}
g.withDetachment(…)
  - Detach.reference // just ids
  - Detach.reduced // ids, labels, keys, values (basically, what you need for toString())
  - Detach.rich // property data included
  - Detached.full // edge data included (basically, StarGraph)
{code}

Next, GraphSON would have to specify a “subtype” to the various g:Element types.

{code}
{ @type:”g:Vertex", @detach:”reference", @value: { id:1 } }
{code}

Then, we could add a method to Element.

{code}
Element.detachment() -> Detach enum
{code}

This way, users can always know what is available to them. Finally for cleanliness:

{code}
Element.detach(Detach) -> Element
Element.attach(Graph) -> Element (always a Detach.full element)
{code}

> 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)