Details
Description
We currently have DetachedXXX and ReferenceXXX classes which are used to "detach" an element from the graph. DetachedXXX are data rich (containing labels, ids, all properties) and ReferenceXXX are data poor (containing only labels and ids). There is a growing need to make this configurable – especially as we promote Gremlin beyond the JVM.
I believe we should have a DetachmentStrategy with the following underlying objects:
- FullDetachedXXX – contains id, label, properties, and incident edges.
- RichDetachedXXX – contains id, label, and properties (what DetachedXXX is now).
- LightDetachedXXX – contains id and label (what ReferenceXXX is now).
- MicroDetachedXXX – contains id.
The default (for backwards compatibility) would be to use "rich detachment."
g.withDetachment(rich).V()... g.withDetachment(light).V()...
Next, once that is solidified, the concepts of "rich", "light", "full", and "micro" should be specified in the corresponding I/O serializations.
{
@type:g:Vertex
@detachment:micro
@value : {
id : 1
}
}
The reason for this is so that deserializers know what type of data to expect and what type of element object to use.
Finally, we could say that instead of specifying strict detachment types, it could all be custom. For instance:
g.withDetachment(T.id,T.label,[edges:[knows],properties:[name,age]])
...where Detachment.rich which simply be a constant compiling to:
T.id,T.label,[edges:[*],properties:[*]]
Attachments
Issue Links
- is related to
-
TINKERPOP-1182 Custom serializers for "detached" classes
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- links to