Build

Building and Testing

To build locally you need to clone the repository to your machine, follow this guide.

Installation & Testing

The ArangoDB TinkerPop Provider can be built locally via

mvn clean install -DskipTests -Dgpg.skip=true

Note that we skip tests since not ALL TinkerPop tests pass (failing ones are known to fail - there are some issues/discrepancies between the tests and how the ArangoDB provider is implemented).

Testing

The ArangoDB TinkerPop Provider is tested against the TinkerPop Test Suite. The test suite if fairly big and can take some time to run. We recomend creating separate run configurations for your tests. For this, the enviromental variable GREMLIN_TESTS can be used to run a specifc test class; the value of the variable must be the quialified name of the test clas you want to run:

For example, to only run the GraphTest class we can set it to org.apache.tinkerpop.gremlin.structure.GraphTest. Then we can run JUnit agaist the ArangoDBGraphTest class. Depending on your prefered development environment configuring this will be different. For example, in Eclipse you can use the Environment tab in the JUnit Run Configuration to set the GREMLIN_TESTS value. In IntelliJ, there is an Environment variables entry that can be used to do the same.

Tests "OK" to Fail

Due to some incompatibilities between what TinkerPop expects form the provider and the ArangoDB implementation, there are some tests that fail. We list some of the known fails and a short description of why. This is not an exhaustive list.

• GraphTest
  • shouldAddVertexWithUSerSuppliedStringId: This is related to how ArangoDB manages docuements' IDs and keys. Implementation wise, in ArangoDB we are only allowed to manipulate the documents key, not its id. For this reason, providing a TinkerPop vertex id (T.id) actually sets the vertex's ArangoDB key. As a result, retreiving the vertex by the given id will fail.
  • shouldEvaluateConnectivityPatterns: Same as above.
• PropertyTest ArangoDB does not store exact type information. So when storing an Integer in the DB, it will be retunred as a Long; value wise it is OK, but TinkerPop tests expect the exact type to be returned. We have added a workaround by storing the preceise value's type when storing the properties and then using this information to restore the value when queried. However, for collections and maps we are not storing the type of each element, so we get expected type discrepancies.
  • supportsSerializableValues: Fails because the mocked class used is not serializable with VPack.