Hi, I need it to keep state. Mapping sql ResultSet's grid nature to a graph nature gets complex quickly and being able to store and manipulate the state of the traverser makes it easier. Also it was possible and the solution presented itself to me as such.
A single row i.e. AbstractStep.processNextStart() from a sql ResultSet might map to many traversers. This is the at the heart of what makes Sqlg a worthwhile enterprise. To fetch lots of data (reduce latency cost) in a denormalized manner and map it to a graph format. To manage this I needed to store state and add a custom method "customSplit(...)". customSplit is similar to split() but it uses and updates the said state. The custom traverser also keeps additional state of where we are with respect to the processNextStart() (a sql row) as I need it in order to calculate the next traverser from the same row. So if all this becomes impossible there is bound to be a different solution to the same problem but it would require quite some thinking and effort. With a little bit of arrogance and ignorance, perhaps letting OLAP constraints leak into OLTP is not a good idea. I'd say OLTP is 99% of use-cases so whatever these serialization issues are they ought to be contained to OLAP. Thanks Pieter On 30/03/2016 21:38, Marko Rodriguez wrote: > 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
