Hi Matt,
Can you explain a bit more of what you mean? Do you mean:
Graph graph = GraphFactory.open(configuration)
Graph g = graph.facade(GiraphGraphComputer)
g.V() …
We could do this, but we are interested in a level of indirection from the
Graph API for the following reasons:
1. GremlinServer can expose TraversalContexts and thus, remote users
only have what is available via the context.
- e.g. no Graph.close(), Graph.io(), Graph.V() when you want
them to use a particular DSL for your system.
2. Graph no longer has V() and E() methods… that is a GraphTraversal
(DSL) concept.
- This makes providing other DSLs as natural as providing
GraphTraversals. GraphTraversal isn't "special."
Thoughts?,
Marko.
http://markorodriguez.com
On Mar 13, 2015, at 9:04 AM, Matt Frantz <[email protected]> wrote:
> Have you considered a GraphFacade approach (which IS-A Graph), in which a
> Graph acts as it does today, but can spawn new facades, each of which
> internally HAS-A context (graph + DSL + engine + strategies)? That would
> accomplish the separation that you seek, but would simplify the simplest
> use case.
>
> On Mon, Mar 9, 2015 at 10:13 AM, 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
>>
>>
