Preliminary work at https://github.com/MichaelMure/git-bug/tree/graphql-transaction

The idea is to be able to

1. open a transaction
2. trigger a bunch of mutations (ex: comment+close)
3. commit the transaction, rollback on error

Benefits would be:

• allow to deal with errors on commit in a single unit of changes and leave bugs in an untouched state
• allow to deal with concurrent editing: the actual bug would not be changed until the transaction commit
• allow to stack together multiple operations in the same git commit

Code wise, the idea is, within the graphql server, attach the raw operation generated by a mutation in a list per transaction and apply it only on commit.

cc @sandhose

@sandhose I don't remember, does it make sense to have those explicit startTransaction, commit and rollback mutation or would it be better to consider all the mutation within a request to be one transaction ? Do we need to have transaction's element spread across multiple call ? Do we need to have the webUI control commit/rollback ?

After discussing with @sandhose it appears that explicit transaction are not worth the added complexity server side.

Best to do an implicit transaction: whatever mutation exist in a single request must be executed server side in order within a transaction. If any one of them fail the whole thing will be discarded and no changes will be made to the data model.

Reflecting back on this, it looks like transaction are not really needed. The main use case was commenting and closing on a bug as a single step but that's pretty much it. This can be implemented as a single GraphQL mutation.

Michael Muré (MichaelMure) closed the bug 4 years ago