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 <https://github.com/apache/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 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. > > >>> > > >> > > > > >