[
https://issues.apache.org/jira/browse/TINKERPOP-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1592.
---------------------------------------
Resolution: Won't Do
Fix Version/s: (was: 3.3.0)
Closing given mailing list discussion. This change doesn't help solve the
problem it proposes to fix.
> 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
>
> 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.4.14#64029)
