[
https://issues.apache.org/jira/browse/TINKERPOP-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15668075#comment-15668075
]
ASF GitHub Bot commented on TINKERPOP-1529:
-------------------------------------------
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/485
I do like `Traversal.metadata()`. However, I think that metadata should be
stored at the root traversal only. Thus, its a global blackboard. Next, given
that its an `Admin` method, it should just use standard Java method naming --
`Traversal.getMetadata()`, `Traversal.setMetadata()`. If the traversal is NOT
the root, then it walks the tree to get the metadata from the root.
If we do the metadata-thang in this ticket, we should update all the MARKER
strategies -- AdjacentToIncident and SubgraphStrategy. (prolly some other?).
I think your `NoBarrier` work should really just be inlined into
`LazyBarrierStragegy` and `PathRetractionStrategy`. Checkout how
`LazyBarrierStrategy` has this notion of labeled paths and path processor ...
its a "switch" to say whether or not to barrier.
> LazyBarrierStrategy is too agressive
> ------------------------------------
>
> Key: TINKERPOP-1529
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1529
> Project: TinkerPop
> Issue Type: Bug
> Components: process
> Affects Versions: 3.2.3
> Reporter: Daniel Kuppitz
> Assignee: Daniel Kuppitz
>
> There are scenarios where {{LazyBarrierStrategy}} changes the semantics of a
> traversal:
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().store("a").out().select("a")
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> {noformat}
> This is actually not the result of {{store()}}, this is {{aggregate()}}. The
> expected result for {{store()}} would be:
> {noformat}
> ==>[v[1]]
> ==>[v[1]]
> ==>[v[1]]
> ==>[v[1],v[2],v[3],v[4]]
> ==>[v[1],v[2],v[3],v[4]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> {noformat}
> Another issue, which should probably go into another ticket, is this:
> {noformat}
> gremlin>
> g.withoutStrategies(LazyBarrierStrategy).V().store("a").out().select("a")
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> {noformat}
> That's it, the console is hanging at this point. Looks like
> {{PathRetractionStrategy}} is the remaining troublemaker. With both
> strategies excluded, we get the expected result:
> {noformat}
> gremlin> g.withoutStrategies(LazyBarrierStrategy,
> PathRetractionStrategy).V().store("a").out().select("a")
> ==>[v[1]]
> ==>[v[1]]
> ==>[v[1]]
> ==>[v[1],v[2],v[3],v[4]]
> ==>[v[1],v[2],v[3],v[4]]
> ==>[v[1],v[2],v[3],v[4],v[5],v[6]]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
