My cuurent attempt tried to do exactly that, but i think I went about it
wrong.
Can I just add it to an existing GraphTraversalSource like this:
graph = TinkerFactory.createModern()
g = graph.traversal()
g.getStrategies().addStrategies(SubgraphStrategy)
subgraph = g.e().hasLabel("Foo").subgraph("subgraph");
...
Sorry if my syntax was a big off trying to rember the syntax for that off
the top of my head. I'm mostly just confused on how to override the
traversal to add a strategy instead of calling withStratagies.
On Sun, Oct 8, 2017 at 12:42 AM, Joshua Shinavier <[email protected]> wrote:
> To pull these threads together:
>
> I have a new Redis-based Graph implementation I can share once I get
> approval from my company. It took about 1600 lines of code and quite a bit
> of time debugging to get it to pass (most) of the structure and process
> standard test suite.
>
> The wrapper I described earlier is only 600 lines of code, but it's less
> full-featured, and the underlying store is already a kind of graph
> database.
>
> Graph-on-Graph wrappers should be simplest of all, but again there's the
> question of whether that's the best approach. To see how a simple strategy
> is applied, try:
>
> graph = TinkerFactory.createModern()
>
> g = graph.traversal()
>
> g =
> g.withStrategies(SubgraphStrategy.build().edges(__.hasLabel("knows")).
> create())
>
> g.E()
>
> A minimal graph wrapper would just override Graph.traversal() to add the
> strategy.
>
> Josh
>
>
>
> On Sat, Oct 7, 2017 at 9:28 PM, Jeffrey Freeman <
> [email protected]> wrote:
>
> > Thanks, may be useful for others who come along. Though I could still use
> > some help. With that said im also trying to understand adding custom
> > strategies to existing providers and having some trouble understanding
> that
> > as well. I seem to have ventured into undocumented territory to some
> > degree.
> >
> > On Sun, Oct 8, 2017 at 12:24 AM, Joshua Shinavier <[email protected]>
> > wrote:
> >
> > > I'm going to paste here what I wrote in a side thread:
> > >
> > >
> > > Well, one reason you don't see a lot of pass-through Graph wrappers in
> > TP3
> > > is that a lot of the things we used to do with wrappers is now
> > accomplished
> > > with traversal strategies. Take IdGraph, for example. This allows you
> to
> > > add the user-defined ID feature to a graph that doesn't natively
> support
> > > it. I wrote this in TP2 as a "wrapper", but in TP3 it became
> > > ElementIdStrategy. Another example is SubgraphStrategy, which takes the
> > > place of a number of Blueprints wrappers for providing a "slice" of the
> > > graph.
> > >
> > > That being said, I think there is still a place for Graph-on-Graph
> > > wrappers, and your template would make it easy to experiment with them.
> > You
> > > should probably make sure you understand traversal strategies, as well;
> > > what you are describing could probably be implemented that way, and
> might
> > > be simpler as a result.
> > >
> > > Btw. combining graph event processing via Apache Storm with an
> on-demand
> > > graph database (Neo4j, JanusGraph) sounds very interesting.
> > >
> > > Josh
> > >
> > > On Sat, Oct 7, 2017 at 9:08 PM, Jeffrey Freeman <
> > > [email protected]> wrote:
> > >
> > > > The past 24 hours ive been trying to write a simple pass-through
> graph
> > > > provider. Basically a Graph type that takes any other Graph type as
> an
> > > > argument in a constructor and passes all calls through to the graph.
> I
> > > want
> > > > to make the framework so someone can then simply override one or two
> > > > methods to do simple extensions to existing providers. A HelloWorld
> > test
> > > i
> > > > am trying to write would be one where all the interactions with the
> > base
> > > > graph would be normal except when setting or getting a property on a
> > edge
> > > > or a vertex in which case if it is a string it appends a "!" to the
> end
> > > > when setting a property. If i can get that minimal functionality
> > working
> > > i
> > > > can reuse and extend those classes to create all sorts of more
> complex
> > > > wrapped graphs. I'd like to make that a library on its own that
> people
> > > can
> > > > use to create easy wrapped graphs which can be used to extend graph
> > > > provider functionality.
> > > >
> > > > After that id use that library to create a more useful real world
> > > utility.
> > > > What i want to do is create a graph that is backed by a traditional
> > graph
> > > > DB (say neo4j or titan) which stores all the nodes and edges, but any
> > > > vertex that has a special property on it would b e treated as a
> message
> > > > queue (like redis in publish and subscribe mode). I want to make it
> so
> > > > messages could be stored in the messaging queue system (redis) but
> its
> > > > content could still be queried from gremlin calls (perhaps treating
> the
> > > > messages a bit like a property that stores an array or something).
> So I
> > > > could essentially create a Titan-redis hybrid or similar that looks
> > like
> > > a
> > > > unified graph. This in turn could be used as a backend to Apache
> Storm
> > in
> > > > order to encode stream topologies in a Tinkerpop / gremlin format. It
> > > would
> > > > also then allow you to perform gremlin queries on the graph to see
> > where
> > > > bottlenecks in the streams happen to be.
> > > >
> > > > Sadly I cant even get a basic passthrough to a tinkergraph to work or
> > > even
> > > > scratch the surface on what im trying to do.
> > > >
> > > > All I really need to see is a simple example of a graph provider
> > wrapper
> > > > but all i keep hearing/seeing are complicated complete solutions. I'm
> > > > starting to doubt its even possible in any feasible way, but i keep
> > > hoping.
> > > >
> > > > If anyone can help me please advise. I used to build stuff like this
> > > easily
> > > > in Tinkerpop2 and I'm trying to resist the urge to go back to
> > Tinkerpop2
> > > > but its becoming more and more likely if i can't get a TP3 solution
> to
> > > > work.
> > > >
> > >
> >
>
