Technically, that is possible. Would I implement it, no. Wrappers just lead to problems as we have seen with Graph strategies.
Marko. http://markorodriguez.com On Apr 13, 2015, at 2:14 PM, Matt Frantz <[email protected]> wrote: > 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 >>>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>>> >> >>
