[jira] [Closed] (TINKERPOP3-655) Traversal Variables

["Marko A. Rodriguez (JIRA)" <ji...@apache.org>]

     [ 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)