[jira] [Commented] (TINKERPOP-1592) Add withDetachment() and specify the "detachment" model.

["Bryn Cooke (JIRA)" <ji...@apache.org>]

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

Bryn Cooke commented on TINKERPOP-1592:
---------------------------------------

Ideally we should be able to specify the properties per label.
Being stuck with reference vertices makes withRemote less useful than is could be. 

> Add withDetachment() and specify the "detachment" model.
> --------------------------------------------------------
>
>                 Key: TINKERPOP-1592
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1592
>             Project: TinkerPop
>          Issue Type: Bug
>          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)