I think it makes sense for this project to be integrated with Spring Data like Neo4j.. It needs to be done right. There was a project that integrated Titan with Spring Data for TP2 through Core,JPA and Neo4j annotations. I am trying to finish the half-made migration to TP3 (that the repo owner did) in that forked project (https://github.com/zifnab87/spring-data-gremlin/tree/TP3-before-merge) (some tests are failing for Tinkergraph still). I will try to replace titan with janusgraph. Hopefully there will be some help from the community so it becomes the official spring-data-gremlin project listed here http://projects.spring.io/spring-data/
I already integrated JanusGraph to the above project by converting existing Titan code and downloading the 0.1.0-SNAPSHOT for JanusGraph in this branch (https://github.com/zifnab87/spring-data-gremlin/tree/janusgraph-integration). About 40 tests are not passing - due to TP2 to TP3 migration not completed yet.
Glad to hear you're working on this @zifnab87! I think this will definitely be well received. I took a quick look and had a few questions. If I'm reading things correctly, the Janus portion will require someone to be running Janus embedded in their Spring app. I was wondering if you'd seen the Apache TinkerPop remote graph functionality? If you used this, I think you could possibly standardize across the different TinkerPop enabled dbs (Orient, Janus, Neo4j) and access them using the TinkerPop drivers remotely in client-server type setup while still getting that embedded feel with the fluent remote graph interface. Essentially your Gremlin queries would stay exactly the same. Schema generation would still be graph db specific and would require putting together strings to send over the driver to their respective db if you weren't running embedded. One other thing, the remote graph does not support the graph methods like addVertex, etc. so you'd need to update your mutation operations to use traversals instead like g.addV, etc.
@twilmes Thanks for the insights! I will have those in mind.. I have a lot of questions to the original author although I haven't gotten any response.. At this point I am still trying to make the inmemory versions of the databases pass the tests because even then there are issues. For JanusGraph I just converted the existing code of Titan. Here is what I have after integrating everything that was available in the orignal author's repo (https://github.com/zifnab87/spring-data-gremlin/tree/feature/TP3_support). I feel I am spinning my wheels now since I don't know some details about jpa/neo4j annotations and some edge cases and what could be supported in the future. I wonder if I could have someone on my side from the janusgraph community to help a bit
Most helpful comment
Glad to hear you're working on this @zifnab87! I think this will definitely be well received. I took a quick look and had a few questions. If I'm reading things correctly, the Janus portion will require someone to be running Janus embedded in their Spring app. I was wondering if you'd seen the Apache TinkerPop remote graph functionality? If you used this, I think you could possibly standardize across the different TinkerPop enabled dbs (Orient, Janus, Neo4j) and access them using the TinkerPop drivers remotely in client-server type setup while still getting that embedded feel with the fluent remote graph interface. Essentially your Gremlin queries would stay exactly the same. Schema generation would still be graph db specific and would require putting together strings to send over the driver to their respective db if you weren't running embedded. One other thing, the remote graph does not support the
graphmethods likeaddVertex, etc. so you'd need to update your mutation operations to use traversals instead likeg.addV, etc.