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 < [email protected]> 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. >
