Postgraphile: Need a mechanism for creating transactions

Created on 18 Jan 2018  路  7Comments  路  Source: graphile/postgraphile

Currently there seems to be no way to create a transaction block (begin and end in postgres). It would be nice if we can specify when a group queries should fail together.

Maybe we should have a special query called transaction in the root:

query {
  ...
  transaction: Query
}

So that the client may form a transaction like this:

query {
  transaction {
    q1 {
      ...
    }
    q2 {
      ...
    }
  }
}

Most helpful comment

That first plugin seems to be exactly what I want, thank you! :)

By the way, that's the main reason I ended up going for Postgraphile instead of Hasura -- its emphasis on making it easy to create plugins to fill gaps in desired functionality. Really great work in that regard.

All 7 comments

All statements are ran through a (single) transaction currently. In GraphQL all fields of a query are ran in parallel, so to do what you suggest would require separate database connections for each transaction field (FYI).

Please could you expand on why you feel multiple transactions would be beneficial to PostGraphile queries?

Since OP hasn't provided a rationale, I think this can be closed for now.

The way I see it, having the ability to execute multiple inter-dependent operations within a single transaction would be valuable for data integrity (e.g. nested mutations). However, the ability to run multiple distinct transactions within a single request doesn't seem to bring any benefits beyond performance optimisation. The request given as an example by OP could equally be split up into two distinct GraphQL requests, without any difference in terms of data-integrity.

I can see scenarios where you would want to run two distinct requests and have each of them fail independently and where sending those two requests within a single roundtrip would provide an ever so slight performance benefit, but it's such an edge-case and the performance benefit is so tiny that it doesn't feel like a feature worth implementing at all.

@benjie

GraphQL seems to have opinions on this, seems to be each mutation resolver would have its own transaction. As such, if you need transactional integrity you need to implement it in a way that results in one mutation field. This could be a custom mutation, nested mutations, or a custom resolver.

Just thought I'd mention that Hasura seems to have support for multiple mutations in one request, executed as a transaction: https://hasura.io/docs/1.0/graphql/core/mutations/multiple-mutations.html

It seems like a useful feature to me. (less need to write "wrapper" mutations that just execute multiple sub-mutations)

@benjie Would you be open to an implementation of it, if someone took the time to write it?

Technically we have multiple mutations in one request, executed as a transaction. However if one of these mutations affected the output of the others it would explicitly go against the behaviour the GraphQL spec prescribes. We actually had to put _more_ effort in to make our implementation spec compliant.

That first plugin seems to be exactly what I want, thank you! :)

By the way, that's the main reason I ended up going for Postgraphile instead of Hasura -- its emphasis on making it easy to create plugins to fill gaps in desired functionality. Really great work in that regard.

Was this page helpful?
0 / 5 - 0 ratings