A mutation can contain multiple fields, just like a query. Ther’s one important distincition between queries and mutation, other than the name:
While query fields are executed in parallel, mutation fields run in series, one after the other.
This means that if we send two incrementCredits mutations in one request, the first is guarenteed to finish before the second begins, ensuring that we don’t end up with a race condition with ourselves.
Is this from the spec or is this dependent on implementation?
I understand that mutations are processed in a single transaction, that is committed automatically. Is there any expansion on this to answer:
Do all mutations in an operation run in the same transaction?
Can mutations be separated into their own transactions?
Does the order of mutations inside an operation effect any of the above?
It is from spec. All “standard” implementations must adhere to the spec.
And the same happens in Dgraph. Mutations are executed serially in the order they are present in the request.
No, in Dgraph each mutation runs in a separate transaction, which is committed before the next mutation in the operation is processed. This is what guarantees the behaviour that the spec expects:
This means that if we send two incrementCredits mutations in one request, the first is guarenteed to finish before the second begins, ensuring that we don’t end up with a race condition with ourselves.
I think, I answered it above. They are already separate.
Answered it at the start itself. Let me clarify it a bit more:
Mutations are executed serially in the order they are present in the request. Where execution of a single mutation consists of these steps in order:
Creating a new transaction
Running the mutation
Committing the transaction
If any error happens in any of the above steps, then the rest of the mutations in the request are not executed.