Dex Implementation

<dependency>
   <groupId>com.tinkerpop.blueprints</groupId>
   <artifactId>blueprints-dex-graph</artifactId>
   <version>??</version>
</dependency>

Graph graph = new DexGraph("/tmp/graph.dex");

Dex is a graph database developed by Sparsity Technologies. For a fine summary of the Dex graph database, please review the following presentations. The software can be downloaded from here and be used with the default evaluation license (which restricts the amount of information Dex can deal with).

Vertex label

As edges, Dex vertices have a label too. Thus, when adding a vertex to the database, its label can be set as follows:

((DexGraph)graph).label.set("people");
Vertex v = graph.addVertex(null)
assertTrue(v.getProperty(StringFactory.LABEL).equals("people"));

The DexGraph#label property is also relevant for other methods. Go to the javadoc of each of the following methods to see how:

• DexGraph#addVertex
• DexGraph#createKeyIndex(String, Class<T>)
• DexGraph#getEdges(String, Object)
• DexGraph#getVertices(String, Object)

Memory Configuration

Dex memory is not managed by the JVM heap, so an specific memory configuration must be set for Dex in order to set the maximum amount of memory to be used by a Dex application.

Specifically, users should set dex.io.cache.maxsize as is explained here.

Managment of Iterable collections

As before, since Dex resources are not managed by the JVM heap, Dex-based blueprints applications should take into account the management of Iterable collections and explicitly close them in order to free native resources.

For example, if we execute a long traversal like this:

for (final Vertex vertex : graph.getVertices()) {
    for (final Edge edge : vertex.getOutEdges()) {
        final Vertex vertex2 = edge.getInVertex();
        for (final Edge edge2 : vertex2.getOutEdges()) {
            ...
        }
    }
}

all retrieved collections won’t be closed until the graph database is stopped. Of course, keep active this amount of resources will have a negative impact in the performance.

To avoid this, all retrieved collections from methods in the Dex implementation implement CloseableIterable. Thus, we could implement the previous traversal as follows:

CloseableIterable<Vertex> vv = (CloseableIterable<Vertex>)graph.getVertices();
for (final Vertex vertex : vv) {
    CloseableIterable<Edge> ee = (CloseableIterable<Edge>)vertex.getOutEdges();
    for (final Edge edge : ee) {
        final Vertex vertex2 = edge.getInVertex();
        CloseableIterable<Edge> ee2 = (CloseableIterable<Edge>)vertex2.getOutEdges();
        for (final Edge edge2 : ee2) {
            ...
        }
        ee2.close();
    }
    ee.close();
}
vv.close();

DexGraph Feature List

supportsDuplicateEdges = true;
supportsSelfLoops = true;
isPersistent = true;
isRDFModel = false;
supportsVertexIteration = true;
supportsEdgeIteration = true;
supportsVertexIndex = false;
supportsEdgeIndex = false;
ignoresSuppliedIds = true;
supportsTransactions = false;
supportsIndices = false;

supportsSerializableObjectProperty = false;
supportsBooleanProperty = true;
supportsDoubleProperty = true;
supportsFloatProperty = true;
supportsIntegerProperty = true;
supportsPrimitiveArrayProperty = false;
supportsUniformListProperty = false;
supportsMixedListProperty = false;
supportsLongProperty = false;
supportsMapProperty = false;
supportsStringProperty = true;

isWrapper = false;
supportsKeyIndices = true;
supportsVertexKeyIndex = true;
supportsEdgeKeyIndex = true;
supportsThreadedTransactions = false;