Hello Pieter,
> In SqlgGraph
> <https://github.com/pietermartin/sqlg/blob/schema/sqlg-core/src/main/java/org/umlg/sqlg/structure/SqlgGraph.java>
> in a static code block invokes
>
> static {
> TraversalStrategies.GlobalCache.registerStrategies(Graph.class,
> TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(new
> SqlgVertexStepStrategy()));
> TraversalStrategies.GlobalCache.registerStrategies(Graph.class,
> TraversalStrategies.GlobalCache.getStrategies(Graph.class).clone().addStrategies(new
> SqlgGraphStepStrategy()));
>
> TraversalStrategies.GlobalCache.getStrategies(Graph.class).setTraverserGeneratorFactory(new
> SqlgTraverserGeneratorFactory());
> }
This all looks great exception the TraverserGeneratorFactory. Traverser classes
are so low-level and so tied to serialization code in OLAP that I removed all
concept of users able to create traverser species. I need full control at that
level to maneuver.
I really need to create a section in the docs that says stuff like:
* Graph System Providers: only implement steps that extend non-final
TinkerPop-steps (e.g. GraphStep, VertexStep, etc.).
* Graph Language Providers: only have Traversal.steps() that can be
represented as a composition of TinkerPop-steps.
When providers get too low level, then its hard for us to maneuver and optimize
and move forward with designs. There are so many assumption in the code that we
make around Traverser instances, Step interfaces, etc. that if people just make
new ones, then strategies, serialization, etc. breaks down.
The question I have, why do you have your own Traverser implementation? I can't
imagine a reason for a provider needs their own traverser class. ??
Thanks,
Marko.
http://markorodriguez.com
