[ 
https://issues.apache.org/jira/browse/TINKERPOP-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette updated TINKERPOP-1592:
----------------------------------------
    Issue Type: Improvement  (was: Bug)

> Add withDetachment() and specify the "detachment" model.
> --------------------------------------------------------
>
>                 Key: TINKERPOP-1592
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1592
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: io, language-variant, process, structure
>    Affects Versions: 3.2.3
>            Reporter: Marko A. Rodriguez
>              Labels: breaking
>             Fix For: 3.3.0
>
>
> 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."
> {code}
> g.withDetachment(rich).V()...
> g.withDetachment(light).V()...
> {code}
> Next, once that is solidified, the concepts of "rich", "light", "full", and 
> "micro" should be specified in the corresponding I/O serializations.
> {code}
> { 
>   @type:g:Vertex
>   @detachment:micro
>   @value : {
>     id : 1
>   }
> }
> {code}
> 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:
> {code}
> g.withDetachment(T.id,T.label,[edges:[knows],properties:[name,age]])
> {code}
> ...where {{Detachment.rich}} which simply be a constant compiling to:
> {code}
> T.id,T.label,[edges:[*],properties:[*]]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to