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