What about a step that would wrap the elements, so that the developer could decide if she wanted them to be springboards for subsequent traversals?
g.traversal().V().out().forTraversal() On Mon, Apr 13, 2015 at 10:17 AM, Marko Rodriguez <[email protected]> wrote: > Hello, > > No, as that reference does not exist and to add it to every Element > produced would be exceeding expensive --- not only from a 64-bit reference > standpoint, but also from a threading standpoint. To make it work, you > would have to wrap each Element produced and that would be an Object > wrapper with a 64-bit reference. Eek. And then in OLAP, where Elements are > created all over the cluster, what 64-bit reference to use?! -- which JVM? > > Marko. > > http://markorodriguez.com > > On Apr 13, 2015, at 10:55 AM, Matt Frantz <[email protected]> > wrote: > > > Could Element.traversal() be a shortcut for returning to the > > TraversalSource that produced the Element? > > > > On Mon, Apr 13, 2015 at 9:07 AM, Marko Rodriguez <[email protected]> > > wrote: > > > >> They are stateless. Create once -- use over and over and over. > >> > >> Marko. > >> > >> http://markorodriguez.com > >> > >> On Apr 13, 2015, at 10:01 AM, Bryn Cooke <[email protected]> wrote: > >> > >>> Hi Marko, > >>> > >>> What is the recommended scope of a TraversalSource? > >>> > >>> Per graph? > >>> Per thread? > >>> > >>> Should I be pooling them? > >>> > >>> Cheers, > >>> > >>> Bryn > >>> > >>> > >>> > >>> On 13/04/15 16:57, Marko Rodriguez wrote: > >>>> Hi Matt, > >>>> > >>>> Yes, that is possible and easy to do, but I would not add it as we > need > >> to stress to people to always go through the same TraversalSource. > >>>> > >>>> The importance of TraversalSource can not be overstated. It is > >> impossible to just have Vertex.out() for the following reasons: > >>>> > >>>> 1. GraphTraversal is just one type of DSL. > >>>> 2. Ignoring 1, then what is the traversal engine that will execute > >> Vertex.out()? Spark, Giraph, standard iterator, GremlinServer, etc.? > >>>> 3. What are the strategies you are applying? You might have > >> ReadOnlyStrategy on g.V(), but then you v.out().remove(). Strategies > gone… > >>>> > >>>> TraversalSource is your "traversal context." Users should always use > >> this. If they want low level methods, they can, but they are not > guaranteed: > >>>> > >>>> 1. An execution engine. > >>>> 2. A set of strategies. > >>>> 3. DSL method chaining. > >>>> > >>>> While we can do v.traversal().out(), you are then creating a new > >> TraversalSource. This is expensive and diverts the user from using the > >> original TraversalSource. For instance, lets say you are working with > >> SparkGraphComputer, the you would have to do this: > >>>> > >>>> v.traversal(computer(SparkComputerEngine)).out() > >>>> > >>>> This creates a new TraversalSource, traversal engine, graph > references, > >> etc… its just not "the way." > >>>> > >>>> Marko. > >>>> > >>>> http://markorodriguez.com > >>>> > >>>> On Apr 13, 2015, at 9:42 AM, Matt Frantz <[email protected]> > >> wrote: > >>>> > >>>>> Could something similar to what was done in splitting Graph and > >>>>> GraphTraversalSource happen with Vertex/Edge? That is: > >>>>> > >>>>> v.traversal().out()... > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Apr 13, 2015 at 7:28 AM, Marko Rodriguez < > [email protected] > >>> > >>>>> wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> You can't start a traversal from any element because GraphTraversal > is > >>>>>> just one type of DSL. For instance, > >>>>>> > >>>>>> vertex.friends().name() > >>>>>> > >>>>>> …would not exist as methods. > >>>>>> > >>>>>> Finally, users can do vertex.edges() if they please, but its not > from > >> a > >>>>>> TraversalSource so its not "DSL"'d. If you want optimizations, > method > >>>>>> chaining, etc., everything must go through a TraversalSource, if > not, > >> its > >>>>>> "raw methods." > >>>>>> > >>>>>> Marko. > >>>>>> > >>>>>> http://markorodriguez.com > >>>>>> > >>>>>> On Apr 13, 2015, at 3:39 AM, Bryn Cooke <[email protected]> > wrote: > >>>>>> > >>>>>>> I have to agree, > >>>>>>> The loss of being able to start a traversal at an element is a real > >>>>>> blow, although I'm sure it was done for good reasons. > >>>>>>> Here are some additional considerations: > >>>>>>> > >>>>>>> * Graph vendors and TP users have different requirements for an API > >>>>>>> that may not be unifiable in a satisfactory way. So perhaps the > >>>>>>> current interfaces are geared towards graph vendors and a wrapper > >>>>>>> could be created for users. Without moving from interfaces to > >>>>>>> abstract classes and therefore gaining the extra power of protected > >>>>>>> scope any unified API will be difficult to achieve. > >>>>>>> * Scala and Groovy have added functionality to make Gremin easier > to > >>>>>>> deal with. The same can and perhaps should be done for Java. Type > >>>>>>> safety and syntactic sugar is available to different degrees in > each > >>>>>>> language, so perhaps we should not try too hard in gremlin core and > >>>>>>> leave that to language specific bindings. In short, gremlin core > >>>>>>> could be targeted to the JVM and Java/Scala/Groovy users have > >>>>>>> something else that happens to allow traversals from elements. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> > >>>>>>> Bryn > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 13/04/15 07:09, pieter-gmail wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I concur with Matthias. > >>>>>>>> > >>>>>>>> Thanks > >>>>>>>> Pieter > >>>>>>>> > >>>>>>>> On 13/04/2015 01:59, Matthias Broecheler wrote: > >>>>>>>>> Hi guys, > >>>>>>>>> > >>>>>>>>> after playing with the M8 release for a bit I wanted to discuss > the > >>>>>>>>> following: With M8, TP3 effectively brings back the distinction > >> between > >>>>>>>>> Blueprints and Gremlin, i.e. there are low level methods for > >> accessing > >>>>>> a > >>>>>>>>> vertex' adjacency list and there are the traversals. > >>>>>>>>> In TP2 that was an issue because developers would start > >> implementing > >>>>>>>>> against Blueprints directly and treat it like a graph library - > not > >>>>>> like a > >>>>>>>>> query language. It can be reasonably assumed that the same will > >> happen > >>>>>> for > >>>>>>>>> TP3. This will be further aggravated by the fact that element > >>>>>> traversals > >>>>>>>>> are no longer supported in TP3. Meaning, you can no longer do > >>>>>>>>> v.out('knows').in('knows") but have to put the vertex back into > the > >>>>>>>>> GraphTraversalSource. That will be very confusing and one can > >> expect > >>>>>> that > >>>>>>>>> user's will prefer using the primitive adjacency list calls > >> instead. > >>>>>>>>> When you have a vertex and you try to traverse out of it, you > will > >>>>>> type in > >>>>>>>>> "v." in your IDE. Lacking any other options, the user will select > >>>>>>>>> "v.edges()", etc. > >>>>>>>>> > >>>>>>>>> I wanted to bring this to your attention since I like the vision > of > >>>>>>>>> "everything is Gremlin". In naming this is true but I am afraid > >> that > >>>>>> actual > >>>>>>>>> user behavior will be different. > >>>>>>>>> > >>>>>>>>> - Why not hide the access methods in the iterator method as was > >> done > >>>>>> in the > >>>>>>>>> last milestone release? > >>>>>>>>> - Should we enforce that the GraphTraversalSource is attached to > >> each > >>>>>>>>> element so that traversing out of it is possible? > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Matthias > >>>>>>>>> > >>>>>> > >>>> > >>> > >> > >> > >
