Thanks @mrjn. Specifically I’m interested in the behavior of the mutations across concurrent upsert blocks. Is the entire upsert block considered one “unit” of work? Or can the mutations within an upsert block get interlaced with mutations from another upsert block happening simultaneously?
Consider the following two upserts executed at the same time, on a person node that is known to exist (ludicrous mode):
upsert {
query {
person as var(func: eq(personId, "47"))
}
mutation {
set {
uid(person) <favoriteColor> "blue" .
uid(person) <favoriteAnimal> "cat" .
}
}
}
and
upsert {
query {
person as var(func: eq(personId, "47"))
}
mutation {
set {
uid(person) <favoriteColor> "green" .
uid(person) <favoriteAnimal> "dog" .
}
}
}
Is the resulting state either
{ favoriteColor: "blue", favoriteAnimal: "cat" }
or
{ favoriteColor: "green", favoriteAnimal: "dog" }
… or could you possibly end up with
{ favoriteColor: "green", favoriteAnimal: "cat" } ?
Additionally, does the behavior differ if the mutations were across multiple mutation blocks within the upserts? Imagine the previous example but instead of the changes all falling within one set block for each upsert, they are split across multiple mutations:
mutation @if(someTrueCond) {
set {
uid(person) <favoriteAnimal> "dog" .
}
}
mutation @if(someOtherTrueCond) {
set {
uid(person) <favoriteColor> "green" .
}
}
Thanks!