hmmm, thanks, im sure ill be back tomorrow with more questions. going to
try to digest this and read up on strategies a  bit more and see where it
gets me. Your help is much appreciated


On Sun, Oct 8, 2017 at 1:07 AM, Joshua Shinavier <[email protected]> wrote:

> Small tweaks to the syntax, but yeah you can create the strategy first,
> then add it to a traversal source, e.g.
>
> strategy = SubgraphStrategy.build().edges(__.hasLabel("knows")).create()
>
> graph = TinkerFactory.createModern()
>
> g = graph.traversal()
>
> g.getStrategies().addStrategies(strategy)
>
> g.E()
>
> Here, SubgraphStrategy is hiding all edges except for "knows".
>
>
>
> On Sat, Oct 7, 2017 at 9:54 PM, Jeffrey Freeman <
> [email protected]> wrote:
>
> > 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.
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to