External IDs and Indices with Concurrent Transactions

Users Dgraph
1

Hi,

We are developing a new schema for a different application that is supposed to share data with our current application as well. We’ve started using the type system and we are trying to create different “views” of the same information as different nodes (per application).

For instance, we may have the type Profile and the type OtherProfile where there is an edge view from Profile to OtherProfile. Most of our calls will deal with the Profile and then based on the application, we would display a certain profile to the user.

Currently in our schema, we have a predicate called id with an index on it. My question is, it appears then when trying to write concurrently to the same id with a different type outside of a transaction, our transaction is aborted for one of the writes.

It is my general understanding that in dgraph that you can’t write to the same index with the same value without this occurring and it is up to the developer to retry the write.

So, I have two questions.

  1. Is my assumption about writing to the same index with the same value above correct?
  2. Am I correct in assuming the only ways around this are one of the following:
  • Write a system to ensure writes are in the same transaction (if the same id is being used)
  • Write a system to ensure writes don’t happen concurrently to the same id
  • Write a system to retry the write using conditional blocks to ensure we don’t retry a write with old data (sort of like a document version like ElasticSearch uses)
  • Use a different predicate per type: profile.id, otherprofile.id, etc...

Just for an example, if I call this mutation in one transaction

_:y <id> "23" .
_:y <dgraph.type> "Profile" .

And at the same time, try to call in a separate transaction:

_:x <id> "23" .
_:x <dgraph.type> "OtherProfile" .

One of the transactions aborts because it is touching the same id on the same index. However, these are two different dgraph.types and ideally we would be able to write to dgraph as fast as possible instead of queuing up writes one type at a time.

EDIT: Is https://dgraph.io/docs/deploy/#ludicrous-mode another option? Is that a terrible idea?

2

That feels like a normal mutation. You had mentioned you used Upsert Block right? in the DM.

Can you share a sample of the Schema?

Totally fine.