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