Re: Im starting a new project, but tinkerpop3 seems incapable, considering forking tinkerpop2

[Jeffrey Freeman]

Awesome, yea let me know, would love to take a look. Much appreciated.

On Wed, Oct 4, 2017 at 1:51 PM, Joshua Shinavier  wrote:

> Sure. I had hacked together a basic implementation, minus tests and a few
> key methods, before I felt compelled to leave for work. Maybe I can put up
> the code tonight or tomorrow morning.
>
> On Wed, Oct 4, 2017 at 10:44 AM, Jeffrey Freeman <
> jeffrey.free...@syncleus.com> wrote:
>
> > I'd love to see that if its available somewhere.
> >
> > On Wed, Oct 4, 2017 at 12:56 PM, Joshua Shinavier 
> > wrote:
> >
> > > That's probably a worthwhile exercise. FYI, I have gotten a start on a
> > > minimal Redis-based impl -- not so much as a template as an example of
> > what
> > > can be done in a few lines of code.
> > >
> > >
> > > On Wed, Oct 4, 2017 at 9:51 AM, Jeffrey Freeman <
> > > jeffrey.free...@syncleus.com> wrote:
> > >
> > > > Thanks, ill try to take a stab at this and write a hello world i can
> > use
> > > as
> > > > a template. If i do such a hello world would it be useful for you
> guys.
> > > >
> > > > On Wed, Oct 4, 2017 at 11:37 AM, Marko Rodriguez <
> okramma...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > You have the following tasks:
> > > > >
> > > > > 1. Implement Graph, Vertex, Edge, VertexProperty, Property
> > > > > interfaces.
> > > > > 2. Implement Transactional interface (optional).
> > > > > 3. Write as many strategies as you want to take advantage
> of
> > > > > provider-specific capabilities.
> > > > > - TinkerGraph itself has 2:
> > > > > https://github.com/apache/
> > > tinkerpop/tree/master/
> > > > > tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/
> > > > > gremlin/tinkergraph/process/traversal/strategy/optimization <
> > > > > https://github.com/apache/tinkerpop/tree/master/
> > > > > tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/
> > > > > gremlin/tinkergraph/process/traversal/strategy/optimization>
> > > > >
> > > > > If you want a minimal “hello world,” then please look at
> TinkerGraph
> > > and
> > > > > Neo4jGraph in our repository. Those are both “reference
> > > implementations.”
> > > > >
> > > > > https://github.com/apache/tinkerpop/tree/master/
> > > > > tinkergraph-gremlin  > tinkerpop/tree/master/
> > > > > tinkergraph-gremlin>
> > > > > https://github.com/apache/tinkerpop/tree/master/neo4j-
> > gremlin
> > > <
> > > > > https://github.com/apache/tinkerpop/tree/master/neo4j-gremlin>
> > > > >
> > > > > Good luck,
> > > > > Marko.
> > > > >
> > > > > http://markorodriguez.com
> > > > >
> > > > >
> > > > >
> > > > > > On Oct 4, 2017, at 5:55 AM, Jeffrey Freeman <
> > > > > jeffrey.free...@syncleus.com> wrote:
> > > > > >
> > > > > > Do you have any examples of what an absolute minimal hello world
> > sort
> > > > of
> > > > > > graph implementation might look like?
> > > > > >
> > > > > > On Wed, Oct 4, 2017 at 12:51 AM, Joshua Shinavier <
> > j...@fortytwo.net
> > > >
> > > > > wrote:
> > > > > >
> > > > > >> Hi Jeffrey,
> > > > > >>
> > > > > >> I agree that simplicity and hackability were a big plus for
> > > > TinkerPop2,
> > > > > and
> > > > > >> that these have taken a bit of a back seat, in TP3, to powerful
> > but
> > > > > >> heavyweight features like backend support for OLAP. The
> > > > > stackable/pluggable
> > > > > >> nature of graph implementations took a a hit, as the
> OOP-friendly
> > > > graph
> > > > > >> interfaces (TransactionalGraph, KeyIndexableGraph,
> IndexableGraph,
> > > > etc.)
> > > > > >> were replaced with the more nuanced GraphFeatures, traversal
> > > > strategies,
> > > > > >> etc.
> > > > > >>
> > > > > >> I wouldn't say that you have to "implement Gremlin" to implement
> > an
> > > > OLTP
> > > > > >> graph, though. You get GraphTraversalSource for free. A summer
> > > intern
> > > > I
> > > > > had
> > > > > >> the pleasure of working with recently wrote a Graph
> implementation
> > > > (as a
> > > > > >> wrapper for another, non-TP graph store) in 660 lines of code.
> > It's
> > > > not
> > > > > so
> > > > > >> hard that one would need to revert to TP2. With TP4 on the
> > horizon,
> > > it
> > > > > >> might be worth making a list of "nice to have (again)"s. There
> are
> > > > some
> > > > > >> features I would like to help to bring back, as well.
> > > > > >>
> > > > > >> Josh
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On Tue, Oct 3, 2017 at 5:49 PM, Jeffrey Freeman <
> > > > > >> jeffrey.free...@syncleus.com> wrote:
> > > > > >>
> > > > > >>> Hi, Some of you may already know me as the author of Ferma.
> This
> > > > thread
> > > > > >> is
> > > > > >>> unrelated to that project, it will continue to support TP2 and
> > TP3
> > > as
> > > > > is.
> > > > > >>>
> > > > > >>> So here's the thing, I sued to use TP2 a lot as part of some
> > > > > frameworks I
> > > > > >>> was working on building (evolutionary algorithms, big data

Re: Im starting a new project, but tinkerpop3 seems incapable, considering forking tinkerpop2

[Joshua Shinavier]

Sure. I had hacked together a basic implementation, minus tests and a few
key methods, before I felt compelled to leave for work. Maybe I can put up
the code tonight or tomorrow morning.

On Wed, Oct 4, 2017 at 10:44 AM, Jeffrey Freeman <
jeffrey.free...@syncleus.com> wrote:

> I'd love to see that if its available somewhere.
>
> On Wed, Oct 4, 2017 at 12:56 PM, Joshua Shinavier 
> wrote:
>
> > That's probably a worthwhile exercise. FYI, I have gotten a start on a
> > minimal Redis-based impl -- not so much as a template as an example of
> what
> > can be done in a few lines of code.
> >
> >
> > On Wed, Oct 4, 2017 at 9:51 AM, Jeffrey Freeman <
> > jeffrey.free...@syncleus.com> wrote:
> >
> > > Thanks, ill try to take a stab at this and write a hello world i can
> use
> > as
> > > a template. If i do such a hello world would it be useful for you guys.
> > >
> > > On Wed, Oct 4, 2017 at 11:37 AM, Marko Rodriguez  >
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > You have the following tasks:
> > > >
> > > > 1. Implement Graph, Vertex, Edge, VertexProperty, Property
> > > > interfaces.
> > > > 2. Implement Transactional interface (optional).
> > > > 3. Write as many strategies as you want to take advantage of
> > > > provider-specific capabilities.
> > > > - TinkerGraph itself has 2:
> > > > https://github.com/apache/
> > tinkerpop/tree/master/
> > > > tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/
> > > > gremlin/tinkergraph/process/traversal/strategy/optimization <
> > > > https://github.com/apache/tinkerpop/tree/master/
> > > > tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/
> > > > gremlin/tinkergraph/process/traversal/strategy/optimization>
> > > >
> > > > If you want a minimal “hello world,” then please look at TinkerGraph
> > and
> > > > Neo4jGraph in our repository. Those are both “reference
> > implementations.”
> > > >
> > > > https://github.com/apache/tinkerpop/tree/master/
> > > > tinkergraph-gremlin  tinkerpop/tree/master/
> > > > tinkergraph-gremlin>
> > > > https://github.com/apache/tinkerpop/tree/master/neo4j-
> gremlin
> > <
> > > > https://github.com/apache/tinkerpop/tree/master/neo4j-gremlin>
> > > >
> > > > Good luck,
> > > > Marko.
> > > >
> > > > http://markorodriguez.com
> > > >
> > > >
> > > >
> > > > > On Oct 4, 2017, at 5:55 AM, Jeffrey Freeman <
> > > > jeffrey.free...@syncleus.com> wrote:
> > > > >
> > > > > Do you have any examples of what an absolute minimal hello world
> sort
> > > of
> > > > > graph implementation might look like?
> > > > >
> > > > > On Wed, Oct 4, 2017 at 12:51 AM, Joshua Shinavier <
> j...@fortytwo.net
> > >
> > > > wrote:
> > > > >
> > > > >> Hi Jeffrey,
> > > > >>
> > > > >> I agree that simplicity and hackability were a big plus for
> > > TinkerPop2,
> > > > and
> > > > >> that these have taken a bit of a back seat, in TP3, to powerful
> but
> > > > >> heavyweight features like backend support for OLAP. The
> > > > stackable/pluggable
> > > > >> nature of graph implementations took a a hit, as the OOP-friendly
> > > graph
> > > > >> interfaces (TransactionalGraph, KeyIndexableGraph, IndexableGraph,
> > > etc.)
> > > > >> were replaced with the more nuanced GraphFeatures, traversal
> > > strategies,
> > > > >> etc.
> > > > >>
> > > > >> I wouldn't say that you have to "implement Gremlin" to implement
> an
> > > OLTP
> > > > >> graph, though. You get GraphTraversalSource for free. A summer
> > intern
> > > I
> > > > had
> > > > >> the pleasure of working with recently wrote a Graph implementation
> > > (as a
> > > > >> wrapper for another, non-TP graph store) in 660 lines of code.
> It's
> > > not
> > > > so
> > > > >> hard that one would need to revert to TP2. With TP4 on the
> horizon,
> > it
> > > > >> might be worth making a list of "nice to have (again)"s. There are
> > > some
> > > > >> features I would like to help to bring back, as well.
> > > > >>
> > > > >> Josh
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Tue, Oct 3, 2017 at 5:49 PM, Jeffrey Freeman <
> > > > >> jeffrey.free...@syncleus.com> wrote:
> > > > >>
> > > > >>> Hi, Some of you may already know me as the author of Ferma. This
> > > thread
> > > > >> is
> > > > >>> unrelated to that project, it will continue to support TP2 and
> TP3
> > as
> > > > is.
> > > > >>>
> > > > >>> So here's the thing, I sued to use TP2 a lot as part of some
> > > > frameworks I
> > > > >>> was working on building (evolutionary algorithms, big data
> > > processing,
> > > > >>> extremely massive datasets, etc). One technique i was leveraging
> is
> > > how
> > > > >>> easy it was for TP2 to support a backend system as a graph. I
> could
> > > > take
> > > > >>> almost any existing system completely unrelated to graph
> databases
> > > and
> > > > by
> > > > >>> simply implementing edges and vertex in blueprints in a few
> > minutes i
> > > > >> could
> > > > >>> have the entire TP2 ec

Re: Im starting a new project, but tinkerpop3 seems incapable, considering forking tinkerpop2

[Jeffrey Freeman]

I'd love to see that if its available somewhere.

On Wed, Oct 4, 2017 at 12:56 PM, Joshua Shinavier  wrote:

> That's probably a worthwhile exercise. FYI, I have gotten a start on a
> minimal Redis-based impl -- not so much as a template as an example of what
> can be done in a few lines of code.
>
>
> On Wed, Oct 4, 2017 at 9:51 AM, Jeffrey Freeman <
> jeffrey.free...@syncleus.com> wrote:
>
> > Thanks, ill try to take a stab at this and write a hello world i can use
> as
> > a template. If i do such a hello world would it be useful for you guys.
> >
> > On Wed, Oct 4, 2017 at 11:37 AM, Marko Rodriguez 
> > wrote:
> >
> > > Hello,
> > >
> > > You have the following tasks:
> > >
> > > 1. Implement Graph, Vertex, Edge, VertexProperty, Property
> > > interfaces.
> > > 2. Implement Transactional interface (optional).
> > > 3. Write as many strategies as you want to take advantage of
> > > provider-specific capabilities.
> > > - TinkerGraph itself has 2:
> > > https://github.com/apache/
> tinkerpop/tree/master/
> > > tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/
> > > gremlin/tinkergraph/process/traversal/strategy/optimization <
> > > https://github.com/apache/tinkerpop/tree/master/
> > > tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/
> > > gremlin/tinkergraph/process/traversal/strategy/optimization>
> > >
> > > If you want a minimal “hello world,” then please look at TinkerGraph
> and
> > > Neo4jGraph in our repository. Those are both “reference
> implementations.”
> > >
> > > https://github.com/apache/tinkerpop/tree/master/
> > > tinkergraph-gremlin  > > tinkergraph-gremlin>
> > > https://github.com/apache/tinkerpop/tree/master/neo4j-gremlin
> <
> > > https://github.com/apache/tinkerpop/tree/master/neo4j-gremlin>
> > >
> > > Good luck,
> > > Marko.
> > >
> > > http://markorodriguez.com
> > >
> > >
> > >
> > > > On Oct 4, 2017, at 5:55 AM, Jeffrey Freeman <
> > > jeffrey.free...@syncleus.com> wrote:
> > > >
> > > > Do you have any examples of what an absolute minimal hello world sort
> > of
> > > > graph implementation might look like?
> > > >
> > > > On Wed, Oct 4, 2017 at 12:51 AM, Joshua Shinavier  >
> > > wrote:
> > > >
> > > >> Hi Jeffrey,
> > > >>
> > > >> I agree that simplicity and hackability were a big plus for
> > TinkerPop2,
> > > and
> > > >> that these have taken a bit of a back seat, in TP3, to powerful but
> > > >> heavyweight features like backend support for OLAP. The
> > > stackable/pluggable
> > > >> nature of graph implementations took a a hit, as the OOP-friendly
> > graph
> > > >> interfaces (TransactionalGraph, KeyIndexableGraph, IndexableGraph,
> > etc.)
> > > >> were replaced with the more nuanced GraphFeatures, traversal
> > strategies,
> > > >> etc.
> > > >>
> > > >> I wouldn't say that you have to "implement Gremlin" to implement an
> > OLTP
> > > >> graph, though. You get GraphTraversalSource for free. A summer
> intern
> > I
> > > had
> > > >> the pleasure of working with recently wrote a Graph implementation
> > (as a
> > > >> wrapper for another, non-TP graph store) in 660 lines of code. It's
> > not
> > > so
> > > >> hard that one would need to revert to TP2. With TP4 on the horizon,
> it
> > > >> might be worth making a list of "nice to have (again)"s. There are
> > some
> > > >> features I would like to help to bring back, as well.
> > > >>
> > > >> Josh
> > > >>
> > > >>
> > > >>
> > > >> On Tue, Oct 3, 2017 at 5:49 PM, Jeffrey Freeman <
> > > >> jeffrey.free...@syncleus.com> wrote:
> > > >>
> > > >>> Hi, Some of you may already know me as the author of Ferma. This
> > thread
> > > >> is
> > > >>> unrelated to that project, it will continue to support TP2 and TP3
> as
> > > is.
> > > >>>
> > > >>> So here's the thing, I sued to use TP2 a lot as part of some
> > > frameworks I
> > > >>> was working on building (evolutionary algorithms, big data
> > processing,
> > > >>> extremely massive datasets, etc). One technique i was leveraging is
> > how
> > > >>> easy it was for TP2 to support a backend system as a graph. I could
> > > take
> > > >>> almost any existing system completely unrelated to graph databases
> > and
> > > by
> > > >>> simply implementing edges and vertex in blueprints in a few
> minutes i
> > > >> could
> > > >>> have the entire TP2 ecosystem working on it and performing
> > traversals.
> > > >> Some
> > > >>> examples of ways i leveraged this in TP2:
> > > >>>
> > > >>> Fusion Graph - A graph driver that allowed me to take two
> completely
> > > >>> different graph systems (say neo4j and titan) and fuse them so they
> > > look
> > > >>> like one graph. I could even connect edges from a vertex in titan
> > with
> > > a
> > > >>> vertex in neo4j.
> > > >>>
> > > >>> Recursive graphs - I could make it so edges could contain clusters
> of
> > > >> edges
> > > >>> and vertexes could contain complete graphs embedded 

Re: Im starting a new project, but tinkerpop3 seems incapable, considering forking tinkerpop2

[Joshua Shinavier]

That's probably a worthwhile exercise. FYI, I have gotten a start on a
minimal Redis-based impl -- not so much as a template as an example of what
can be done in a few lines of code.


On Wed, Oct 4, 2017 at 9:51 AM, Jeffrey Freeman <
jeffrey.free...@syncleus.com> wrote:

> Thanks, ill try to take a stab at this and write a hello world i can use as
> a template. If i do such a hello world would it be useful for you guys.
>
> On Wed, Oct 4, 2017 at 11:37 AM, Marko Rodriguez 
> wrote:
>
> > Hello,
> >
> > You have the following tasks:
> >
> > 1. Implement Graph, Vertex, Edge, VertexProperty, Property
> > interfaces.
> > 2. Implement Transactional interface (optional).
> > 3. Write as many strategies as you want to take advantage of
> > provider-specific capabilities.
> > - TinkerGraph itself has 2:
> > https://github.com/apache/tinkerpop/tree/master/
> > tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/
> > gremlin/tinkergraph/process/traversal/strategy/optimization <
> > https://github.com/apache/tinkerpop/tree/master/
> > tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/
> > gremlin/tinkergraph/process/traversal/strategy/optimization>
> >
> > If you want a minimal “hello world,” then please look at TinkerGraph and
> > Neo4jGraph in our repository. Those are both “reference implementations.”
> >
> > https://github.com/apache/tinkerpop/tree/master/
> > tinkergraph-gremlin  > tinkergraph-gremlin>
> > https://github.com/apache/tinkerpop/tree/master/neo4j-gremlin <
> > https://github.com/apache/tinkerpop/tree/master/neo4j-gremlin>
> >
> > Good luck,
> > Marko.
> >
> > http://markorodriguez.com
> >
> >
> >
> > > On Oct 4, 2017, at 5:55 AM, Jeffrey Freeman <
> > jeffrey.free...@syncleus.com> wrote:
> > >
> > > Do you have any examples of what an absolute minimal hello world sort
> of
> > > graph implementation might look like?
> > >
> > > On Wed, Oct 4, 2017 at 12:51 AM, Joshua Shinavier 
> > wrote:
> > >
> > >> Hi Jeffrey,
> > >>
> > >> I agree that simplicity and hackability were a big plus for
> TinkerPop2,
> > and
> > >> that these have taken a bit of a back seat, in TP3, to powerful but
> > >> heavyweight features like backend support for OLAP. The
> > stackable/pluggable
> > >> nature of graph implementations took a a hit, as the OOP-friendly
> graph
> > >> interfaces (TransactionalGraph, KeyIndexableGraph, IndexableGraph,
> etc.)
> > >> were replaced with the more nuanced GraphFeatures, traversal
> strategies,
> > >> etc.
> > >>
> > >> I wouldn't say that you have to "implement Gremlin" to implement an
> OLTP
> > >> graph, though. You get GraphTraversalSource for free. A summer intern
> I
> > had
> > >> the pleasure of working with recently wrote a Graph implementation
> (as a
> > >> wrapper for another, non-TP graph store) in 660 lines of code. It's
> not
> > so
> > >> hard that one would need to revert to TP2. With TP4 on the horizon, it
> > >> might be worth making a list of "nice to have (again)"s. There are
> some
> > >> features I would like to help to bring back, as well.
> > >>
> > >> Josh
> > >>
> > >>
> > >>
> > >> On Tue, Oct 3, 2017 at 5:49 PM, Jeffrey Freeman <
> > >> jeffrey.free...@syncleus.com> wrote:
> > >>
> > >>> Hi, Some of you may already know me as the author of Ferma. This
> thread
> > >> is
> > >>> unrelated to that project, it will continue to support TP2 and TP3 as
> > is.
> > >>>
> > >>> So here's the thing, I sued to use TP2 a lot as part of some
> > frameworks I
> > >>> was working on building (evolutionary algorithms, big data
> processing,
> > >>> extremely massive datasets, etc). One technique i was leveraging is
> how
> > >>> easy it was for TP2 to support a backend system as a graph. I could
> > take
> > >>> almost any existing system completely unrelated to graph databases
> and
> > by
> > >>> simply implementing edges and vertex in blueprints in a few minutes i
> > >> could
> > >>> have the entire TP2 ecosystem working on it and performing
> traversals.
> > >> Some
> > >>> examples of ways i leveraged this in TP2:
> > >>>
> > >>> Fusion Graph - A graph driver that allowed me to take two completely
> > >>> different graph systems (say neo4j and titan) and fuse them so they
> > look
> > >>> like one graph. I could even connect edges from a vertex in titan
> with
> > a
> > >>> vertex in neo4j.
> > >>>
> > >>> Recursive graphs - I could make it so edges could contain clusters of
> > >> edges
> > >>> and vertexes could contain complete graphs embedded inside them, they
> > >> could
> > >>> even be defined by completely different underlying systems. This gave
> > me
> > >> a
> > >>> sort of hierarchical graph.
> > >>>
> > >>> Apache Storm graphs - I was able to encapsulate the topology from
> > apache
> > >>> storm as a graph so one could perform traversals across a storm
> > topology
> > >> as
> > >>> it is running to produce statistic

Re: Im starting a new project, but tinkerpop3 seems incapable, considering forking tinkerpop2

[Jeffrey Freeman]

Thanks, ill try to take a stab at this and write a hello world i can use as
a template. If i do such a hello world would it be useful for you guys.

On Wed, Oct 4, 2017 at 11:37 AM, Marko Rodriguez 
wrote:

> Hello,
>
> You have the following tasks:
>
> 1. Implement Graph, Vertex, Edge, VertexProperty, Property
> interfaces.
> 2. Implement Transactional interface (optional).
> 3. Write as many strategies as you want to take advantage of
> provider-specific capabilities.
> - TinkerGraph itself has 2:
> https://github.com/apache/tinkerpop/tree/master/
> tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/
> gremlin/tinkergraph/process/traversal/strategy/optimization <
> https://github.com/apache/tinkerpop/tree/master/
> tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/
> gremlin/tinkergraph/process/traversal/strategy/optimization>
>
> If you want a minimal “hello world,” then please look at TinkerGraph and
> Neo4jGraph in our repository. Those are both “reference implementations.”
>
> https://github.com/apache/tinkerpop/tree/master/
> tinkergraph-gremlin  tinkergraph-gremlin>
> https://github.com/apache/tinkerpop/tree/master/neo4j-gremlin <
> https://github.com/apache/tinkerpop/tree/master/neo4j-gremlin>
>
> Good luck,
> Marko.
>
> http://markorodriguez.com
>
>
>
> > On Oct 4, 2017, at 5:55 AM, Jeffrey Freeman <
> jeffrey.free...@syncleus.com> wrote:
> >
> > Do you have any examples of what an absolute minimal hello world sort of
> > graph implementation might look like?
> >
> > On Wed, Oct 4, 2017 at 12:51 AM, Joshua Shinavier 
> wrote:
> >
> >> Hi Jeffrey,
> >>
> >> I agree that simplicity and hackability were a big plus for TinkerPop2,
> and
> >> that these have taken a bit of a back seat, in TP3, to powerful but
> >> heavyweight features like backend support for OLAP. The
> stackable/pluggable
> >> nature of graph implementations took a a hit, as the OOP-friendly graph
> >> interfaces (TransactionalGraph, KeyIndexableGraph, IndexableGraph, etc.)
> >> were replaced with the more nuanced GraphFeatures, traversal strategies,
> >> etc.
> >>
> >> I wouldn't say that you have to "implement Gremlin" to implement an OLTP
> >> graph, though. You get GraphTraversalSource for free. A summer intern I
> had
> >> the pleasure of working with recently wrote a Graph implementation (as a
> >> wrapper for another, non-TP graph store) in 660 lines of code. It's not
> so
> >> hard that one would need to revert to TP2. With TP4 on the horizon, it
> >> might be worth making a list of "nice to have (again)"s. There are some
> >> features I would like to help to bring back, as well.
> >>
> >> Josh
> >>
> >>
> >>
> >> On Tue, Oct 3, 2017 at 5:49 PM, Jeffrey Freeman <
> >> jeffrey.free...@syncleus.com> wrote:
> >>
> >>> Hi, Some of you may already know me as the author of Ferma. This thread
> >> is
> >>> unrelated to that project, it will continue to support TP2 and TP3 as
> is.
> >>>
> >>> So here's the thing, I sued to use TP2 a lot as part of some
> frameworks I
> >>> was working on building (evolutionary algorithms, big data processing,
> >>> extremely massive datasets, etc). One technique i was leveraging is how
> >>> easy it was for TP2 to support a backend system as a graph. I could
> take
> >>> almost any existing system completely unrelated to graph databases and
> by
> >>> simply implementing edges and vertex in blueprints in a few minutes i
> >> could
> >>> have the entire TP2 ecosystem working on it and performing traversals.
> >> Some
> >>> examples of ways i leveraged this in TP2:
> >>>
> >>> Fusion Graph - A graph driver that allowed me to take two completely
> >>> different graph systems (say neo4j and titan) and fuse them so they
> look
> >>> like one graph. I could even connect edges from a vertex in titan with
> a
> >>> vertex in neo4j.
> >>>
> >>> Recursive graphs - I could make it so edges could contain clusters of
> >> edges
> >>> and vertexes could contain complete graphs embedded inside them, they
> >> could
> >>> even be defined by completely different underlying systems. This gave
> me
> >> a
> >>> sort of hierarchical graph.
> >>>
> >>> Apache Storm graphs - I was able to encapsulate the topology from
> apache
> >>> storm as a graph so one could perform traversals across a storm
> topology
> >> as
> >>> it is running to produce statistics or to effect its behavior based on
> >>> traffic or usage
> >>>
> >>> MapDB graphs - using MapDB as a graph backend or even a traditional
> >>> database or any other storage system not usually seen a a graph.
> >>>
> >>> The list is really endless. But the problem I'm facing with TP3 is that
> >> it
> >>> is no longer trivial to implement a Graph. Now you have to pretty much
> >>> implement Gremlin for your graph and countless other methods. I get why
> >>> this is done, from a performance standpoint if your going to view
> gremlin

Re: Im starting a new project, but tinkerpop3 seems incapable, considering forking tinkerpop2

[Marko Rodriguez]

Hello,

You have the following tasks:

1. Implement Graph, Vertex, Edge, VertexProperty, Property interfaces.
2. Implement Transactional interface (optional).
3. Write as many strategies as you want to take advantage of 
provider-specific capabilities.
- TinkerGraph itself has 2:

https://github.com/apache/tinkerpop/tree/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/process/traversal/strategy/optimization
 


If you want a minimal “hello world,” then please look at TinkerGraph and 
Neo4jGraph in our repository. Those are both “reference implementations.”

https://github.com/apache/tinkerpop/tree/master/tinkergraph-gremlin 

https://github.com/apache/tinkerpop/tree/master/neo4j-gremlin 


Good luck,
Marko.

http://markorodriguez.com



> On Oct 4, 2017, at 5:55 AM, Jeffrey Freeman  
> wrote:
> 
> Do you have any examples of what an absolute minimal hello world sort of
> graph implementation might look like?
> 
> On Wed, Oct 4, 2017 at 12:51 AM, Joshua Shinavier  wrote:
> 
>> Hi Jeffrey,
>> 
>> I agree that simplicity and hackability were a big plus for TinkerPop2, and
>> that these have taken a bit of a back seat, in TP3, to powerful but
>> heavyweight features like backend support for OLAP. The stackable/pluggable
>> nature of graph implementations took a a hit, as the OOP-friendly graph
>> interfaces (TransactionalGraph, KeyIndexableGraph, IndexableGraph, etc.)
>> were replaced with the more nuanced GraphFeatures, traversal strategies,
>> etc.
>> 
>> I wouldn't say that you have to "implement Gremlin" to implement an OLTP
>> graph, though. You get GraphTraversalSource for free. A summer intern I had
>> the pleasure of working with recently wrote a Graph implementation (as a
>> wrapper for another, non-TP graph store) in 660 lines of code. It's not so
>> hard that one would need to revert to TP2. With TP4 on the horizon, it
>> might be worth making a list of "nice to have (again)"s. There are some
>> features I would like to help to bring back, as well.
>> 
>> Josh
>> 
>> 
>> 
>> On Tue, Oct 3, 2017 at 5:49 PM, Jeffrey Freeman <
>> jeffrey.free...@syncleus.com> wrote:
>> 
>>> Hi, Some of you may already know me as the author of Ferma. This thread
>> is
>>> unrelated to that project, it will continue to support TP2 and TP3 as is.
>>> 
>>> So here's the thing, I sued to use TP2 a lot as part of some frameworks I
>>> was working on building (evolutionary algorithms, big data processing,
>>> extremely massive datasets, etc). One technique i was leveraging is how
>>> easy it was for TP2 to support a backend system as a graph. I could take
>>> almost any existing system completely unrelated to graph databases and by
>>> simply implementing edges and vertex in blueprints in a few minutes i
>> could
>>> have the entire TP2 ecosystem working on it and performing traversals.
>> Some
>>> examples of ways i leveraged this in TP2:
>>> 
>>> Fusion Graph - A graph driver that allowed me to take two completely
>>> different graph systems (say neo4j and titan) and fuse them so they look
>>> like one graph. I could even connect edges from a vertex in titan with a
>>> vertex in neo4j.
>>> 
>>> Recursive graphs - I could make it so edges could contain clusters of
>> edges
>>> and vertexes could contain complete graphs embedded inside them, they
>> could
>>> even be defined by completely different underlying systems. This gave me
>> a
>>> sort of hierarchical graph.
>>> 
>>> Apache Storm graphs - I was able to encapsulate the topology from apache
>>> storm as a graph so one could perform traversals across a storm topology
>> as
>>> it is running to produce statistics or to effect its behavior based on
>>> traffic or usage
>>> 
>>> MapDB graphs - using MapDB as a graph backend or even a traditional
>>> database or any other storage system not usually seen a a graph.
>>> 
>>> The list is really endless. But the problem I'm facing with TP3 is that
>> it
>>> is no longer trivial to implement a Graph. Now you have to pretty much
>>> implement Gremlin for your graph and countless other methods. I get why
>>> this is done, from a performance standpoint if your going to view gremlin
>>> as a query language for graph databases it is needed. But what i need is
>>> some middle ground where I can still implement a Graph as easy as i could
>>> in TP2 even if the end result is rather poor performance on the gremlin
>>> queries (which can be optimized later in some cases as the development
>>> matures).
>>> 
>>> As far as i can tell this just isnt possible in TP3, correct me if im
>> wrong
>>> because I'd love to use it for these use cas

Re: Im starting a new project, but tinkerpop3 seems incapable, considering forking tinkerpop2

[Jeffrey Freeman]

Do you have any examples of what an absolute minimal hello world sort of
graph implementation might look like?

On Wed, Oct 4, 2017 at 12:51 AM, Joshua Shinavier  wrote:

> Hi Jeffrey,
>
> I agree that simplicity and hackability were a big plus for TinkerPop2, and
> that these have taken a bit of a back seat, in TP3, to powerful but
> heavyweight features like backend support for OLAP. The stackable/pluggable
> nature of graph implementations took a a hit, as the OOP-friendly graph
> interfaces (TransactionalGraph, KeyIndexableGraph, IndexableGraph, etc.)
> were replaced with the more nuanced GraphFeatures, traversal strategies,
> etc.
>
> I wouldn't say that you have to "implement Gremlin" to implement an OLTP
> graph, though. You get GraphTraversalSource for free. A summer intern I had
> the pleasure of working with recently wrote a Graph implementation (as a
> wrapper for another, non-TP graph store) in 660 lines of code. It's not so
> hard that one would need to revert to TP2. With TP4 on the horizon, it
> might be worth making a list of "nice to have (again)"s. There are some
> features I would like to help to bring back, as well.
>
> Josh
>
>
>
> On Tue, Oct 3, 2017 at 5:49 PM, Jeffrey Freeman <
> jeffrey.free...@syncleus.com> wrote:
>
> > Hi, Some of you may already know me as the author of Ferma. This thread
> is
> > unrelated to that project, it will continue to support TP2 and TP3 as is.
> >
> > So here's the thing, I sued to use TP2 a lot as part of some frameworks I
> > was working on building (evolutionary algorithms, big data processing,
> > extremely massive datasets, etc). One technique i was leveraging is how
> > easy it was for TP2 to support a backend system as a graph. I could take
> > almost any existing system completely unrelated to graph databases and by
> > simply implementing edges and vertex in blueprints in a few minutes i
> could
> > have the entire TP2 ecosystem working on it and performing traversals.
> Some
> > examples of ways i leveraged this in TP2:
> >
> > Fusion Graph - A graph driver that allowed me to take two completely
> > different graph systems (say neo4j and titan) and fuse them so they look
> > like one graph. I could even connect edges from a vertex in titan with a
> > vertex in neo4j.
> >
> > Recursive graphs - I could make it so edges could contain clusters of
> edges
> > and vertexes could contain complete graphs embedded inside them, they
> could
> > even be defined by completely different underlying systems. This gave me
> a
> > sort of hierarchical graph.
> >
> > Apache Storm graphs - I was able to encapsulate the topology from apache
> > storm as a graph so one could perform traversals across a storm topology
> as
> > it is running to produce statistics or to effect its behavior based on
> > traffic or usage
> >
> > MapDB graphs - using MapDB as a graph backend or even a traditional
> > database or any other storage system not usually seen a a graph.
> >
> > The list is really endless. But the problem I'm facing with TP3 is that
> it
> > is no longer trivial to implement a Graph. Now you have to pretty much
> > implement Gremlin for your graph and countless other methods. I get why
> > this is done, from a performance standpoint if your going to view gremlin
> > as a query language for graph databases it is needed. But what i need is
> > some middle ground where I can still implement a Graph as easy as i could
> > in TP2 even if the end result is rather poor performance on the gremlin
> > queries (which can be optimized later in some cases as the development
> > matures).
> >
> > As far as i can tell this just isnt possible in TP3, correct me if im
> wrong
> > because I'd love to use it for these use cases. If that turns out to be
> > true and no one here has any better ideas (which id very much welcome) my
> > next resort would be to revive TP2, fork it as a new project under a new
> > name, and continue to maintain it as a solution that addresses some of
> > these needs. i welcome any ideas or inputs from the community on this for
> > me.
> >
>

Re: Im starting a new project, but tinkerpop3 seems incapable, considering forking tinkerpop2

[Joshua Shinavier]

Hi Jeffrey,

I agree that simplicity and hackability were a big plus for TinkerPop2, and
that these have taken a bit of a back seat, in TP3, to powerful but
heavyweight features like backend support for OLAP. The stackable/pluggable
nature of graph implementations took a a hit, as the OOP-friendly graph
interfaces (TransactionalGraph, KeyIndexableGraph, IndexableGraph, etc.)
were replaced with the more nuanced GraphFeatures, traversal strategies,
etc.

I wouldn't say that you have to "implement Gremlin" to implement an OLTP
graph, though. You get GraphTraversalSource for free. A summer intern I had
the pleasure of working with recently wrote a Graph implementation (as a
wrapper for another, non-TP graph store) in 660 lines of code. It's not so
hard that one would need to revert to TP2. With TP4 on the horizon, it
might be worth making a list of "nice to have (again)"s. There are some
features I would like to help to bring back, as well.

Josh



On Tue, Oct 3, 2017 at 5:49 PM, Jeffrey Freeman <
jeffrey.free...@syncleus.com> wrote:

> Hi, Some of you may already know me as the author of Ferma. This thread is
> unrelated to that project, it will continue to support TP2 and TP3 as is.
>
> So here's the thing, I sued to use TP2 a lot as part of some frameworks I
> was working on building (evolutionary algorithms, big data processing,
> extremely massive datasets, etc). One technique i was leveraging is how
> easy it was for TP2 to support a backend system as a graph. I could take
> almost any existing system completely unrelated to graph databases and by
> simply implementing edges and vertex in blueprints in a few minutes i could
> have the entire TP2 ecosystem working on it and performing traversals. Some
> examples of ways i leveraged this in TP2:
>
> Fusion Graph - A graph driver that allowed me to take two completely
> different graph systems (say neo4j and titan) and fuse them so they look
> like one graph. I could even connect edges from a vertex in titan with a
> vertex in neo4j.
>
> Recursive graphs - I could make it so edges could contain clusters of edges
> and vertexes could contain complete graphs embedded inside them, they could
> even be defined by completely different underlying systems. This gave me a
> sort of hierarchical graph.
>
> Apache Storm graphs - I was able to encapsulate the topology from apache
> storm as a graph so one could perform traversals across a storm topology as
> it is running to produce statistics or to effect its behavior based on
> traffic or usage
>
> MapDB graphs - using MapDB as a graph backend or even a traditional
> database or any other storage system not usually seen a a graph.
>
> The list is really endless. But the problem I'm facing with TP3 is that it
> is no longer trivial to implement a Graph. Now you have to pretty much
> implement Gremlin for your graph and countless other methods. I get why
> this is done, from a performance standpoint if your going to view gremlin
> as a query language for graph databases it is needed. But what i need is
> some middle ground where I can still implement a Graph as easy as i could
> in TP2 even if the end result is rather poor performance on the gremlin
> queries (which can be optimized later in some cases as the development
> matures).
>
> As far as i can tell this just isnt possible in TP3, correct me if im wrong
> because I'd love to use it for these use cases. If that turns out to be
> true and no one here has any better ideas (which id very much welcome) my
> next resort would be to revive TP2, fork it as a new project under a new
> name, and continue to maintain it as a solution that addresses some of
> these needs. i welcome any ideas or inputs from the community on this for
> me.
>

Im starting a new project, but tinkerpop3 seems incapable, considering forking tinkerpop2

[Jeffrey Freeman]

Hi, Some of you may already know me as the author of Ferma. This thread is
unrelated to that project, it will continue to support TP2 and TP3 as is.

So here's the thing, I sued to use TP2 a lot as part of some frameworks I
was working on building (evolutionary algorithms, big data processing,
extremely massive datasets, etc). One technique i was leveraging is how
easy it was for TP2 to support a backend system as a graph. I could take
almost any existing system completely unrelated to graph databases and by
simply implementing edges and vertex in blueprints in a few minutes i could
have the entire TP2 ecosystem working on it and performing traversals. Some
examples of ways i leveraged this in TP2:

Fusion Graph - A graph driver that allowed me to take two completely
different graph systems (say neo4j and titan) and fuse them so they look
like one graph. I could even connect edges from a vertex in titan with a
vertex in neo4j.

Recursive graphs - I could make it so edges could contain clusters of edges
and vertexes could contain complete graphs embedded inside them, they could
even be defined by completely different underlying systems. This gave me a
sort of hierarchical graph.

Apache Storm graphs - I was able to encapsulate the topology from apache
storm as a graph so one could perform traversals across a storm topology as
it is running to produce statistics or to effect its behavior based on
traffic or usage

MapDB graphs - using MapDB as a graph backend or even a traditional
database or any other storage system not usually seen a a graph.

The list is really endless. But the problem I'm facing with TP3 is that it
is no longer trivial to implement a Graph. Now you have to pretty much
implement Gremlin for your graph and countless other methods. I get why
this is done, from a performance standpoint if your going to view gremlin
as a query language for graph databases it is needed. But what i need is
some middle ground where I can still implement a Graph as easy as i could
in TP2 even if the end result is rather poor performance on the gremlin
queries (which can be optimized later in some cases as the development
matures).

As far as i can tell this just isnt possible in TP3, correct me if im wrong
because I'd love to use it for these use cases. If that turns out to be
true and no one here has any better ideas (which id very much welcome) my
next resort would be to revive TP2, fork it as a new project under a new
name, and continue to maintain it as a solution that addresses some of
these needs. i welcome any ideas or inputs from the community on this for
me.