In TinkerPop can vertex properties contain complex objects?

Question

I am playing with TinkerGraph and gremlin-scala and I see that it is capable of persisting complex objects:

case class InnerObj(a: Int, b: String)
case class ComplexObj(a: Int, b: InnerObj)
case class SuperComplexObj(a : String, b: ComplexObj)

class GremlinQueriesSpec extends FlatSpec
  with ScalaFutures with MustMatchers {

  behavior of "Gremlin queries"

  it must "be able to persist complex objects containing collections" taggedAs Integration in {

    val g = TinkerGraph.open()
    implicit val graph = g.asScala

    val user = RandomData.randomUserDataAggregate

    graph + user

    graph.V().toCC[UserDataAggregate].toList() must be eq List(user)
  }
}

However, docs are not completely clear to me. On еру one hand there's not much structure available for property values besides lists, sets, and metaproperties. On the other hand docs say:

A Property denotes a key/value pair associated with an Edge. A property is much like a Java8 Optional in that a property can be not present (i.e. empty). The key of a property is always a String and the value of a property is an arbitrary Java object. Each underlying graph engine will typically have constraints on what Java objects are allowed to be used as values.

Ok, it looks like it depends on the implementation. But is possible to work with nested objects in Gremlin queries?

Answer 1

It is indeed dependent on the implementation. You are using TinkerGraph which can in turn store any Java object so you're free to put whatever you like in there:

gremlin> g.addV().property('function',{it.length()})
==>v[2]
gremlin> g.V().sideEffect{println(it.get().value('function')("four"))}
4
==>v[2]

crazy right? Of course, you will need to consider issues like serialization and such if you start sticking random odds/ends in there and need to persist those objects or push them over the wire (like through Gremlin Server).

There is no problem with a nested object as a value for a TinkerGraph property. Just be careful. Really stop to think about your schema before going to deep down the path of storing complex Java objects as properties. Perhaps it would be better to just model those objects as elements of the graph as first class citizens to enable Gremlin traversals to work over them directly.