Using Blueprints for GraphDatabase

[David Winslow]

Hi all, I'm investigating an improvement that we have been discussing for some time - implementing the GraphDatabase API on top of Blueprints.  Since Blueprints is a compatibility layer with adapters for many graph databases this would make it a little easier for us to experiment with alternatives, and to customize GeoGit for beefy servers or resource-constrained mobile devices.

I am far from having things working but in the spirit of "release early, release often" I have uploaded the first thing that compiled to Github :)

https://github.com/dwins/GeoGit/compare/blueprints

My plan is to port the existing Neo4J graphdatabase to use the Blueprints Neo4j adapter, and then factor out configuration options until we can support alternative Blueprints backends.  The next steps will be to investigate all the test failures that arose as a result of switching things around (Blueprints is not quite a drop-in replacement for the native Neo4J interface.)

--

David Winslow

OpenGeo - http://opengeo.org/

[Gabriel Roldan]

Hey David, this looks like a good first step, thanks for taking this over.

Gave it a quick glimpse and my only question so far is if it wouldn't be better to go straight with the Graph superinterface instead of Neo4jGraph, since after all the spirit is to code the graph algorithms against the generic blueprints API?

In any case, I'm sure you'll work it out, thanks for the hard work and go blueprints!

Cheers,

Gabriel

P.S. thanks to JD too for having implemented all the graph algorithms with no real attachment to Neo4J other than the data access API calls.

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[David Winslow]

The Graph interface does not expose transactions or index operations, so defining the blueprints graph database in terms of it would require casts or some changes to avoid relying on those features (and I think we should demand indexes and transactions, right?)

Unfortunately we cannot define the variable as "something that implements both IndexedGraphDatabase and TransactionalGraphDatabase" but we could do that as a bound on a type parameter.  Once I get the tests passing again I will attempt to refactor to a generic base class like:

abstract class BlueprintsGraphDatabase<DB extends IndexedGraphDatabase, TransactionalGraphDatabase> {

    private DB graphDatabase;

    public DB createDatabase();

}

Hopefully this won't be too burdensome on implementers, otherwise we can just fall back to casts.

--

David Winslow

OpenGeo - http://opengeo.org/