1

I have defined in my schema constraints to ensure uniqueness of given vertices based one or more properties. For example:
mgmt.buildIndex('byTenandIdUnique',Vertex.class).addKey(tenantId).unique().buildCompositeIndex()

As expected now, when I try to add a Vertex that already exists, I am getting an error like below:

aiogremlin.exception.GremlinServerError: 500: Adding this property for key [tenantId] and value [ACME2_AX2] violates a uniqueness constraint [byTenandIdUnique]

I am writing a Python application to load log files, with Goblin OGM, so it is expected that the data will repeat, and I don't want multiple instances of the same Vertex, hence the constraint.

Is there a way in TinkerPop or JanusGraph to update a Vertex in case it already exists instead of throwing this exception? Or is this something that the OGM should handle or maybe the code itself by querying the graph before any transaction?

Cracoras
  • 347
  • 3
  • 16

1 Answers1

2

TinkerPop does not do anything to enforce a schema, so the schema restriction here is specific to JanusGraph. The behavior is as you described: if you have a unique index defined and then attempt to add another element that conflicts with an existing element, an exception is thrown.

From a JanusGraph perspective, your logic will need to account for this properly. The code below is based on a common recipe using the coalesce() step that you can read more about here.

// check for existence of a vertex with the tenantId property
// if the vertex exists, return that vertex
// else create a new vertex with the tenantId
v = g.V().property("tenantId", "ACME2_AX2").fold(). \
    coalesce( __.unfold(), __.addV().property("tenantId", "ACME2_AX2") ). \
    next();

I don't use Goblin, so I'm not aware of whether Goblin is capable of handling this or whether it passes that responsibility on to the app developer, but checking for existence before setting the property is still an appropriate way to handle the situation.

Jason Plurad
  • 6,682
  • 2
  • 18
  • 37