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