Marko A. Rodriguez created TINKERPOP3-607:
---------------------------------------------
Summary: Extend the concept of DetachedXXX
Key: TINKERPOP3-607
URL: https://issues.apache.org/jira/browse/TINKERPOP3-607
Project: TinkerPop 3
Issue Type: New Feature
Components: io, structure
Affects Versions: 3.0.0.GA
Reporter: Marko A. Rodriguez
Many moons ago we had {{ReferencedVertex}}, {{ReferencedEdge}}, etc. These were
extremely simply objects of the form:
{noformat}
public ReferenceVertex implements Vertex {
private final Object id;
...
}
{noformat}
We got rid of these in favor of having ONLY {{DetachedVertex}},
{{DetachedEdge}}, etc. However, I think there is more to the story of
"detachment." Here is the landscape I see:
*DETACH SEMANTICS*
* Detach for reference -- detach a vertex so it can later be attached to the
same graph.
* Detach for adding -- detach a vertex so it can later be added to another
graph.
*ATTACH SEMANTICS*
* Attach to an existing graph -- find the actual vertex that is referenced by
this detached vertex and return the actual vertex.
* Add to an existing graph -- add the detached vertex to the graph.
If, lets say, a property is detached "for adding" then the only information it
needs to have is its {{String}} key and {{Object}} value. There is no need to
have a reference to its original element, etc.
Likewise, if, lets say, a vertex is detached "for adding" then the only
information it needs to have is its {{Object}} id and {{String}} label.
However, if its detached "for reference" then all it needs is its {{Object}} id.
These subtleties are important when considering how much big the
{{DetachedXXX}} objects are and how regularly they are used in Gremlin OLAP and
Gryo. We should really consider the minimal amount of data needed in all these
areas....
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
