Hi guys,
Here is, literally, the gist of the API change:
https://gist.github.com/okram/5ed0ab32a91887681b43
As you can see, from a Graph, you can spawn a "TraversalContext." A repeat of
benefits this new level of indirection:
1. The OLAP GraphComputer to use is not global to the graph but
"context" dependent.
- super important for Hadoop where you may have a
SparkGraphComputer and GiraphGraphComputer both executing against the same
HadoopGraph.
2. If GremlinServer simply exposes TraversalContexts, then users can't
g.close(). They can only do GraphTraversal stuff.
3. User DSLs are easy to spawn. We have computer and standard as "easy
public static finals", but for a user DSL.
- graph.traversal(MyDSLContext.build())
-
graph.traversal(MyDSLContext.build().engine(ComputerTraversalEngine.build()))
4. You can provide context dependent strategies -- Stephen and I will
be working on this today and will demonstrate later.
Note that the code is in newapi/ branch. Comments welcome.
Enjoy,
Marko.
http://markorodriguez.com
On Mar 10, 2015, at 12:44 PM, Matt Franklin <[email protected]> wrote:
> On Tue, Mar 10, 2015 at 7:04 AM Rob Vesse <[email protected]> wrote:
>
>> All
>>
>> It is clear from the email forwarded below (and others like it) that there
>> is a lot of developer discussion going on behind the scenes which then
>> turns into brain dumps to the dev@ list. Ideally as much discussion as is
>> possible and is practical should be occurring asynchronously on the dev@
>> list so that it is visible to the community and the community have a
>> chance to chime into the discussions ASAP
>>
>
> I was going to raise this exact same point, but probably not as eloquently
> as Rob. In the Apache Way, decisions and discussions happen in public.
> There is a saying that accompanies this principle:
>
> "If it didn't happen on the list, it didn't happen"
>
>
>>
>> I have no doubt that you guys are doing good work on Tinkerpop and are
>> clearly having in-depth developer discussions between yourselves (whether
>> F2F, IM, Skype or some other medium) but doing this creates a barrier of
>> entry for newcomers to the community because it gives the impression
>> (which may/may not be warranted) that there is a private inner circle
>> handing down decisions which is not how ASF projects should operate any
>> only serves to get projects in trouble with the board.
>>
>> I am not trying to say that this is the case here since you are looking to
>> solicit community feedback but really you should be involving the
>> community in discussions earlier in the process and it could look that way
>> to someone who hasn't been following the list so closely.
>>
>> Note that clearly we don't expect people at the ASF to never have
>> discussions off-list because that would be impractical and unrealistic (if
>> you sit next to someone you are going to talk to them) but you need to
>> make sure any relevant discussions move on-list as soon as is practical
>> which you are already doing to some extent with emails like the one
>> forwarded but it feels like you could be doing so earlier.
>>
>> Rob
>>
>> On 09/03/2015 17:13, "Marko Rodriguez" <[email protected]> wrote:
>>
>>> Hi everyone,
>>>
>>> We have reached a wall regarding the following problems:
>>>
>>> 1. GraphStrategies via wrappers is not working for various vendors.
>>> 2. TraversalEngine is specific to a Graph and thus, global to all
>>> traversals spawned off that graph.
>>> 3. User defined Traversal DSLs are not easily created and are not
>>> susceptible to OLAP processing.
>>>
>>> As a solution, Stephen and I are bouncing around the idea of a
>>> TraversalContext:
>>>
>>> Graph graph = GraphFactory.open(configuration);
>>> GraphTraversalContext g = graph.traversal(GraphTraversal.of()
>>> .engine(StandardTraversalEngine.
>> instance())
>>> .strategy(ReadOnlyTraversalStrategy.
>> instance()));
>>> g.V().out().values("name").iterate();
>>> g.V().values("age").iterate(); // spawn as many traversals as you want
>>> off of g
>>>
>>> In essence, we want to introduce one new level of indirection from the
>>> Graph to the Traversal. This new level is called a "TraversalContext" (no
>>> better name yet) and it bundles the following objects:
>>>
>>> 1. Graph (the raw data structure)
>>> 2. Traversal DSL (GraphTraversal, SocialTraversal, etc. etc.)
>>> 3. TraversalEngine (Spark, Giraph, Standard, etc.)
>>> 4. TraversalStrategies (ReadOnlyTraversalStrategy,
>> IdTraversalStrategy,
>>> PartitionTraversalStrategy, etc.)
>>>
>>> You can see a working implementation of GraphTraversalContext here:
>>> https://gist.github.com/okram/e67252705a920cd34571
>>>
>>> What problems does this solve beyond 1,2, and 3 above?
>>>
>>> 1. Graph.Iterators.vertexIterator() -> Graph.vertices() // back
>> to a
>>> "Blueprints"-style API for people wanting to work with the graph object
>>> directly
>>> 2. Graph.engine() goes away -- no more ThreadLocal hack.
>>> 3. Graph.of(Traversal.class) goes away -- we will be DSL friendly
>> with
>>> TraversalContext.
>>> 4. Graph.V() goes away -- its all in terms of the traversal
>> context.
>>> GraphTraversalContext.V() exists.
>>>
>>> One big pill that must be swallowed with this model -- Vertex.outE()
>>> doesn't exist:
>>>
>>> Vertex v = g.V().out().next()
>>> String name = g.V(v).out().values("name")
>>>
>>> Graph, Vertex, Edge, etc. no longer have Traversal methods off of them
>>> (that is NOT DSL friendly). Therefore, everything is off of
>>> TraversalContext. This is actually going to make DSL execution on
>>> GraphComputer extremely easy and its going to simplify vendor strategy
>>> code a lot -- strategies are simply cached with respects to MyGraph.class.
>>>
>>> Anywho… its a big deal. Functionally, things don't really change. Its
>>> just a reorganization that is going to ultimately solve 1-3 in the
>>> beginning which need solving before we release GA.
>>>
>>> If anyone has any thoughts/concerns with the desired change, please raise
>>> them.
>>>
>>> Thanks,
>>> Marko.
>>>
>>> http://markorodriguez.com
>>>
>>
>>
>>
>>
>>
