[ 
https://issues.apache.org/jira/browse/TINKERPOP3-820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marko A. Rodriguez closed TINKERPOP3-820.
-----------------------------------------
    Resolution: Won't Fix

Going to close this as there is no easy was to modulate a traversal after its 
been compiled. [~pietermartin-tinkerpop] if you still feel this is necessary, 
please reopen and provide more argument.

Note that there are plans to make the {{MatchAlgorithms}} implement some sort 
of {{RuntimeStrategy}} which we can then propagate to {{OrStep}}, {{AndStep}}, 
etc. In fact, making a ticket now about that.

> Change steps after the strategy phase.
> --------------------------------------
>
>                 Key: TINKERPOP3-820
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP3-820
>             Project: TinkerPop 3
>          Issue Type: Improvement
>          Components: process
>    Affects Versions: 3.0.1-incubating
>            Reporter: pieter martin
>            Assignee: Marko A. Rodriguez
>
> Hi,
> I am working on optimizing the order() step for sqlg (generating the order by 
> clause in the sql).
> So far I have been collapsing steps in the strategy phase. However to 
> optimize the order() clause I need to pre-parse the (so-far) collapsed step 
> to know whether a OrderGlobalStep step can be optimized or not.
> For a traversal starting from a GraphStep this is ok as the traversal starts 
> from a label which is available and thus the pre-parser has all the 
> information it needs available to it at the strategy phase.
> For a traversal that starts from a VertexStep the start vertex is only known 
> runtime (after iterating) so the pre-parser can only execute at runtime to 
> gather the information needed to optimize the OrderGlobalStep. This means in 
> order to optimize a the traversal I need to change the steps after starting 
> the iteration.
> Unfortunately the traversal is locked and I am unable to optimize steps 
> whilst iterating.
> I removed the lock code and my optimizations are working fine. All tests pass 
> except for the lock specific test 
> {{CoreTraversalTest.shouldNotAlterTraversalAfterTraversalBecomesLocked}}.
> Is removing or disabling the lock something that will be considered.
> Bit like a JIT compiler, we can change the execution strategy/step/path after 
> having started the iteration.
> Thanks
> Pieter



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to