That would be great but just having union in TP3 changes a lot. I will have to test everything out and see if we can work with existing steps to do everything.
On Wed, May 6, 2015 at 12:52 PM, Daniel Kuppitz <[email protected]> wrote: > hey Dylan, > > that would be __.union(__.out("brother"), __.out("sister")) => > __.union(__.out("brother", "sister")) => __.out("brother", "sister") > Nice idea, but as Marko already mentioned > <https://issues.apache.org/jira/browse/TINKERPOP3-664>, we need to make > sure that we do not introduce too much compilation overhead. > > However, a new new strategy doesn't necessarily mean, that it's used by > default, hence nobody prevents us from implementing more and more > strategies. I have a few more in mind and will also consider your example - > but feel free to submit a PR if you think you can provide a solid > implementation. > > Cheers, > Daniel > > > On Wed, May 6, 2015 at 6:01 PM, Dylan Millikin <[email protected]> > wrote: > > > @Marko > > > > Yeah I've been following - and quite excited about - traversal > strategies. > > It's a great step forward for the optimisation of automated scripts. > > > > There are also a couple of steps we would love to see in gremlin that > would > > just make it golden, the main one being a .merge() step that would serve > to > > concatenate non permutable steps. For example: > > __.out('brother').merge(.out('sister')) that would give __.out('brother', > > 'sister'). This is something our libraries currently handle in TP2 but > they > > imply way too much maintenance as we need to keep track of gremlin method > > signatures. > > I was going to wait for GA to build a case for it as I currently have > > little experience with gremlin3. (The rewrite of our application for TP3 > > will give me more insight on that end) > > > > Anyways, great job as always. TP3 is really exciting. > > Dylan. > > > > On Wed, May 6, 2015 at 11:25 AM, Marko Rodriguez <[email protected]> > > wrote: > > > > > Hi everyone, > > > > > > I just republished the SNAPSHOT JavaDocs. Check out the > TraversalStrategy > > > interface > > > > > > > > > > > > http://tinkerpop.incubator.apache.org/javadocs/3.0.0-SNAPSHOT/full/org/apache/tinkerpop/gremlin/process/traversal/TraversalStrategy.html > > > > > > ….and then click on known implementing classes. E.g. > > > > > > > > > > > > http://tinkerpop.incubator.apache.org/javadocs/3.0.0-SNAPSHOT/full/org/apache/tinkerpop/gremlin/process/traversal/strategy/optimization/AdjacentToIncidentStrategy.html > > > > > > > > > http://tinkerpop.incubator.apache.org/javadocs/3.0.0-SNAPSHOT/full/org/apache/tinkerpop/gremlin/process/traversal/strategy/decoration/ConjunctionStrategy.html > > > > > > > > > http://tinkerpop.incubator.apache.org/javadocs/3.0.0-SNAPSHOT/full/org/apache/tinkerpop/gremlin/process/traversal/strategy/verification/LambdaRestrictionStrategy.html > > > etc. > > > > > > We now have @examples that show rewrites for those that are interested. > > > > > > Enjoy, > > > Marko. > > > > > > http://markorodriguez.com > > > > > > On May 6, 2015, at 9:12 AM, Daniel Kuppitz <[email protected]> wrote: > > > > > > > FYI: I just pushed the aforementioned IncidentToAdjacentStrategy to > > > master > > > > < > > > > > > https://github.com/apache/incubator-tinkerpop/blob/c395647fe70d750118478d13d7729f51591eea1d/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/optimization/IncidentToAdjacentStrategy.java > > > > > > > > . > > > > > > > > On Wed, May 6, 2015 at 12:39 PM, Daniel Kuppitz <[email protected]> > > wrote: > > > > > > > >> Hey guys, > > > >> > > > >> we just wanted to let you know that Gremlin is getting smarter and > > > >> smarter. We added a new traversal optimizer strategy: > > > >> AdjacentToIncidentStrategy > > > >> <https://issues.apache.org/jira/browse/TINKERPOP3-654> (previously > > > called > > > >> HalfStepTraversalStrategy). > > > >> > > > >> *What does it do?* > > > >> > > > >> It looks for typical patterns / step sequences in traversals that > > > involve > > > >> a significant performance overhead (especially in OLAP), and > replaces > > > them > > > >> with "shorter" alternatives. > > > >> > > > >> *A few examples:* > > > >> > > > >> OriginalOptimizedg.V().out().count()g.V().outE().count() > > > >> g.V().in().limit(3).count()g.V().inE().limit(3).count() > > > >> g.V().values("name").count()g.V().properties("name").count() > > > >> g.V().has(__.out())g.V().has(__.outE())g.V().has(__.values()) > > > >> g.V().has(__.properties()) > > > >> > > > >> *What's next?* > > > >> > > > >> Now that we have AdjacentToIncidentStrategy, it's time to create an > > > >> IncidentToAdjacentStrategy. No kidding, the other way can be an > > > >> optimization too. Consider the following traversal: > > > >> > > > >> > > > > > > g.V().outE().inV().has(__.out("friend")).has(__.outE("workedAt").inV().has("name", > > > >> "FooBar LLC")) > > > >> > > > >> > > > >> Believe me, I've seen a lot of queries like this in the past. But > now, > > > >> after applying the two aforementioned strategies, we would end up > > with: > > > >> > > > >> > g.V().out().has(__.outE("friend")).has(__.out("workedAt").has("name", > > > >> "FooBar LLC")) > > > >> > > > >> > > > >> Pretty cool, isn't it? > > > >> > > > >> Cheers, > > > >> Daniel > > > >> > > > >> > > > >> > > > > > > > > >
