[
https://issues.apache.org/jira/browse/TINKERPOP3-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko A. Rodriguez closed TINKERPOP3-655.
-----------------------------------------
Resolution: Won't Fix
This problem is being solved in Titan specifically via a very simple fix that
[~mbroecheler] and I came up with some time ago. I forget the specifics but
[~mbroecheler] knows them and will do it accordingly for Titan.
> Traversal Variables
> -------------------
>
> Key: TINKERPOP3-655
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-655
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.0.0-incubating
> Reporter: stephen mallette
> Assignee: stephen mallette
>
> This is a fresh issue created out of TINKERPOP3-593 (it may have other
> origins as well) where it was deemed to be a bit of a separate issue that
> requires more thought and consideration.
> One of the values of {{Traversal}} and the {{TraversalStrategy}} model is in
> the idea that it is possible to apply strategies and then clone the traversal
> without having to re-apply those strategies for later execution. The thought
> is that some future strategies may be expensive to apply and that repeated
> application of them will be redundant and hurt query execution time.
> At this time, a {{Traversal}} applies all of its strategies at execution
> time. If you were to clone that {{Traversal}} the strategies would be
> re-applied. Such a thing is likely easily rectified, but even with that
> change, an important problem would remain: the {{Traversal}} is bound to the
> values provided to it.
> For example in {{g.V(1).out('knows')}}, this {{Traversal}} will always be
> executed and optimized given the start step having vertex id of "1" and the
> out label as "knows". For this to work properly a {{Traversal}} needs to be
> optimized based on something like
> {{g.V(Variable.of('x')).out(Variable.of("y"))}}. In this way the
> {{Traversal}} can track for itself what parameters can have substitution.
> As a side note, it would be possible for users with groovy and the Gremlin
> Server to write the above as: {{g.V( x ).out( y )}} where the "x" and "y"
> could be dynamically converted to {{Variable}} object bindings.
> There have been several methods discussed in trying to elevate the concept of
> {{Variable}} to a first class citizen:
> 1. Tracking the {{Variable}} external to the {{Traversal}} where the
> {{Traversal}} looks up its value at execution time. This approach was nice
> as it didn't force any change to the existing API, but it brought many
> limitations (e.g. for steps with multiple parameters, it became hard/ugly to
> track where that {{Variable}} was supposed to be).
> 2. Treating {{Variable}} as a polymorphous object that basically implements
> all possible interfaces so that it can be passed to all existing
> {{Traversal}} methods. This sorta works, but breaks down when generally
> applied because it won't support enums like {{Direction}} and it since
> {{Number}} is an abstract class, you can't multi-inherit to {{Boolean}}
> (which is final anyway). There is a basic example of this working in this
> branch: https://github.com/apache/incubator-tinkerpop/tree/variables but it
> falls short of showing how variables get re-bound at execution time.
> 3. Alter {{Traversal}} and all {{Step}} implementations to take {{Variable}}
> as an argument. In its most extreme form, this would be the most radical
> method and would introduce a lot of extra methods to the API (a variablized
> version of every step method), but would truly make {{Variable}} first-class
> across the board. In a more reserved form, where we looked at specific
> {{Traversal}} methods that would benefit from a {{Variable}} it could be more
> surgical.
> As it stands, option 3 in its "reserved form" seems like the best solution,
> though a number of questions remained:
> 1. What step methods would benefit the most from taking {{Variable}}?
> Certainly those that might affect query routing would be one (i.e.
> {{g.V(id).out()}}).
> 2. What does it mean to partially apply strategies? The problem here is that
> strategies build on one another and possibly have dependencies. If a strategy
> is dependent on the value of a field that is a {{Variable}} it won't be able
> to be applied and thus would block downstream strategies from execution. If
> the "expensive" strategy we hope to save execution on is in the downstream,
> we won't see the savings.
> 3. Based on 2, we can sorta roll back to 1, because a {{Variable}} in certain
> steps might always block partial application of the strategy set.
> 4. How will a {{Variable}} be tracked and substituted after partial
> application of the strategies?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
