TinkerPop and TinkerGraph

The 0.5.1 module embeds TinkerGraph and maps the common repository contract onto TinkerPop/Gremlin. It is the fastest local verification path and a useful algorithm/test fixture, but it does not reproduce remote server latency, durability, clustering, or a vendor’s transaction model.

Use TinkerGraphOperations.kt for synchronous work and TinkerGraphSuspendOperations.kt for coroutine integration. CRUD/traversal behavior is covered by TinkerGraphOperationsTest.kt; commit and rollback are covered by TinkerGraphTransactionTest.kt.

Prefer it for unit tests, tutorials, and a first graph model. Before moving to another backend, rerun merge, batch, schema, transaction, property-type, and traversal tests there. An in-memory pass proves domain logic, not infrastructure readiness.

Run and observe the in-memory boundary

dependencies {
    implementation(platform("io.github.bluetape4k:bluetape4k-dependencies:<ecosystem-version>"))
    implementation("io.github.bluetape4k:bluetape4k-graph-tinkerpop")
}

TinkerGraphOperations().use { ops ->
    val a = ops.createVertex("Person", mapOf("name" to "Alice"))
    val b = ops.createVertex("Person", mapOf("name" to "Bob"))
    ops.createEdge(a.id, b.id, "KNOWS")
    check(ops.neighbors(a.id, NeighborOptions(edgeLabel = "KNOWS")).single().id == b.id)
}

./gradlew :bluetape4k-graph-tinkerpop:test --tests '*TinkerGraphTransactionTest'

Observe and diagnose the in-memory limit

Expected: one outgoing neighbor and transaction snapshot rollback on injected failure. No container or network is involved. Therefore connection loss, server concurrency, durability, cluster failover, and remote Gremlin behavior remain untested. If a later backend disagrees, keep the TinkerGraph result as a domain baseline and diagnose the candidate’s property types, transaction/schema capability, and query translation. use owns the in-memory operations only.