Transactions in GraphQL

Dev
, ,
13

Seems like there are a bunch of different things that we are thinking of implementing here.

  1. Automatically retry mutations on conflict - I am assuming this applies to a single mutation which is being committed right away? We’d have to be careful to only retry only in the case where there is an actual conflict and not when for e.g. an xid already exists etc. otherwise we might be stuck retrying mutations that might never succeed.

  2. Execute all mutations atomically - This seems an easy one to do and also has been asked by some users. What you have here looks good with the @transaction directive on the mutation.

  3. Expose the transaction functionality to the user - Something similar to what we do in Dgraph would work here. I doubt this can be combined with the retry functionality because we would allocate new timestamps for retries.
    I would propose this for the semantics.

  • @transaction without any arguments starts a new transaction and returns the startTs in response headers or extensions. Also @transaction(commit: true) starts a new transaction, commits it if possible or rollbacks any mutations.
  • @transaction(id: 123) executes an operation with that startTs.
  • @transaction(id: 123, commit: true) commits the transaction.
  • @transaction(id: 123, abort: true) aborts it.
1 Like