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