I guess what you want to avoid is a new set of interfaces like
VertexForTraversal, EdgeForTraversal, etc. That's a fair point.
What a developer has to do now is something like this:
t = g.traversal().V().out()
while (t.hasNext()) {
v = t.next();
vt = g.traversal().V(v);
vt.out()...;
}
In effect, the proposed "forTraversal" (or perhaps "asTraversal" or just
"traversal") step would simply produce those "vt" traversals.
If you wanted both the element and the springboard, you could use select:
g.traversal().V().out().as('v').traversal().as('vt').select('v', 'vt');
On Mon, Apr 13, 2015 at 1:19 PM, Marko Rodriguez <[email protected]>
wrote:
> 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
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
