Implementations

In order to connect a graph database to Blueprints, the Blueprints property graph interfaces must be implemented. For non-native Blueprints graph databases, the raw graph database API and the Blueprints API need to be coupled. For native Blueprints graph databases, no such coupling is needed as only the interfaces need to be implemented. Each subsection discusses the various implementations of the Blueprints interfaces maintained by the main Blueprints distribution.

DEPENDENCY NOTE: It is important to note that including a <dependency/> to Blueprints does not entail all the respective graph database/framework dependencies distributed with Blueprints. The reason for this is that it allows users to include only those graph implementations they wish for their particular projects (e.g. based on licensing, size, performance, etc.).

Developer Notes

This section defines the general rules and standards by which Blueprints implementations are expected to work. By following these implementation details, developers implementing the Blueprints API can expect consistent operations throughout the TinkerPop stack. Many of these details are enforced by the Blueprints test suite, so there will be little choice in those areas when it comes to implementation, however others are merely convention and not explicitly enforced. Choosing not to following convention will introduce risk that the implementation will not work as expected elsewhere in the stack.

getVertex/Edge

The getVertex and getEdge methods on the Graph class accept an object type as the parameter for the respective vertex or edge identifier. Always coerce that identifier to its expected type. If the underlying graph, only expects a long as an identifier, then ensure that the parameter is converted to a long (as it may come in as a String or other such value). If the identifier cannot be coerced to its expected type then simply return null.

The identifier parameter cannot be null and if it is an exception should immediately be thrown:

if (null == id)
    throw ExceptionFactory.vertexIdCanNotBeNull();

Other Tests

In addition to the Blueprints Test Suite, developers have the option to test their implementations with other test suites higher in the stack. These tests can help uncover other problems that the Blueprints tests don’t (however, efforts are made to push the logic higher level tests down to Blueprints when problems are found). Running these tests can provide additional confidence that there is consistency all the way to the top of the TinkerPop stack.

Rexster Integration Tests

Rexster has a suite of integration tests that runs across multiple graphs to validate operational consistency of implementations. To run the tests:

1. Copy the jar file of the Blueprints implementation to the REXSTER_HOME/ext directory.
2. Pull the Rexster source code from GitHub and edit the rexster.xml used by the integration tests to include the graph configuration to include in the tests.
3. Execute: mvn clean install -Pintegration-test from the command line.