4

I want to provide a GraphQL service that runs the whole mutation operation in a single transaction (all or nothing changes).

The toplevel fields are processed serially in a single transaction and change the database accordingly. Only when there is no error during execution, the changes should be committed to the database, else they should all be rolled back.

Now I have two questions:

  1. According to the GraphQL specification, serial execution of the toplevel fields means each toplevel field will be filled out with a value that reflects the state after its modification, before it is known if a later field causes an error. Is it intended that this is not the actual value of the field when a later toplevel field causes an error which rolls back the transaction?

  2. If a mutation of a toplevel field fails, it makes no sense to execute the following toplevel fields, as the transaction may be in a state that prevents further processing and all changes will be rolled back anyway. Is it ok, according to the GraphQL semantic, to skip execution of those fields (returning null and maybe an entry to the errors list)?

Leisetreter
  • 133
  • 1
  • 9
  • 2
    it all depends on ur backend implementation, it has nothing to do with GraphQL. GraphQL is just an interface to how you interact with the backend. – Mox Dec 20 '16 at 09:00
  • 1
    yes, ok, but it is also a question of best practices/API user expectations. – Leisetreter Dec 20 '16 at 09:29

1 Answers1

7

I'm afraid you misunderstood that part of GraphQL specification. If I understand your question, you are thinking of DB write/update operations of the transaction as separate mutations.

GraphQL has a mutation root object, which can have one or more top level fields. These top level fields are the individual mutations. If we want a service with transaction behavior, we'll implement it as a single mutation. The back-end implementation has to deal with how to ensure transactional behavior.

The part of the specification that got you confused pertains to what happens when there are multiple mutation top-level fields (selection set). Each mutation is independent.

Ahmad Ferdous
  • 3,351
  • 16
  • 33
  • 1
    I interpret the spec like this: there is one GraphQL operation in the GraphQL request, which is a mutation. The mutation serially modifies the top level fields (as implemented at the server by the side-effects of resolving the field). Now, I want to put all those top-level field modifications in one transaction. The question is, so to say, can the spec be interpreted so that the side-effects of resolving a top level field don't perform any work once a top level field had an error? – Leisetreter Dec 21 '16 at 07:35
  • No, the spec cannot be _interpreted_ that way. GraphQL does not have anything to do with transaction. It's just an interface to your data stored behind the scene using your choice of storage (persistent or non-persistent). Transaction has to be dealt past GraphQL layer. – Ahmad Ferdous Dec 21 '16 at 17:57