tinkerpop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Frantz (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TINKERPOP3-655) Traversal Variables
Date Wed, 05 Aug 2015 03:44:04 GMT

    [ https://issues.apache.org/jira/browse/TINKERPOP3-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654763#comment-14654763

Matt Frantz commented on TINKERPOP3-655:

This comment addresses the design concern around supporting variables in arbitrary locations
in the API.  An approach like TINKERPOP3-799 could apply here, in that a step modulator might
reduce the amount of overloading required to allow parameter substitution in many places in
the API where {{String}} is already accepted.
t = g.V().has('foo', 'x').variable('x').out()...
t.iterate()  // Raise exception because of unspecified variables
t1 = t.substitute('x', 'bar')
t2 = t.substitute('x', 'baz')
Variable modulation could also apply to {{P}}.
t = g.V().has('name', gte('x').variable('x')).out()...
t1 = t.substitute('x', 'bar')

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

This message was sent by Atlassian JIRA

View raw message