Transactions in GraphQL

This was de-prioritized for Q3 while we are building out other high priority user requested features. We’ll look at this again when we come for the Roadmap for the next quarter in November.

Hi Guys, has this been readded to the roadmap?

1 Like

Any update?

What about changing it to:

This will mean open a new transaction, do m1 and m2, then commit, otherwise fail all.

mutation @transaction {
 m1(...) {...}
 m2(...) {...}
}

This will mean keep the transaction open and return the details in the extensions.

mutation @transaction(commit: false) {
 m1(...) {...}
 m2(...) {...}
}

In determining which of these two is a better option, I think the key question here is whether most users are more likely to want to commit the transaction in a single request, or if in general they’re more likely to want to return the transaction to do some more client-side work before committing. Also, what would be the most natural expectation for developers?

My guess is that most would expect @transaction to commit everything (if there are no errors), unless otherwise stated, but maybe more experienced Dgraph users would feel differently.

Any update on the roadmap for this?

Thanks.

Hey @pawan @vvbalaji , could you both investigate the need / feasibility of this?

1 Like

A post was split to a new topic: Issue with Dgo

Hi, we would like add our vote to support @transaction directive using GraphQL. Lack of transaction support in GraphQL means you have to use DQL transactions, which means that you have update manually the reverse edges as far we understand. This add a lot of complexity on any business logic, that would be simplified if we had the transaction directive on GraphQL.

2 Likes

Just want to place my vote to for this to be prioritised. The issue I have is that because there are no validations in DQL, then it creates a situation where DQL mutations in my codebase can easily become outdated as the schema evolves—which could lead to a situation where an outdated DQL mutation is running in production creating bad data, which leads to broken graphql queries because endpoints start returning non nullable field errors:

"Non-nullable field 'platform' (type String!) was not present in result from Dgraph.  GraphQL error propagation triggered.

Which of course is not a situation you can resolve with a couple of clicks.

Until DQL has validations, or transactions are possible in graphql I’m gonna feel nervous every time I modify the schema.

4 Likes

Hey, more than one year later, is there a solution meanwhile?
I am very much looking forward to the feature :slight_smile: