Hi all,
If an action contained several transactions (for example persisted a bunch of objects), is there a way to rollback all of these transactions if any of those failed? Like adding a layer of atomicity in the actions. If possible I’d love to avoid tracing and reverting all changes.
Thanks!
I’m not sure what happens if e.g. one item of many in a Persist All action isn’t persistable (e.g. has a non-unique value in a unique field). If all the others are persisted, then I think you need to build some custom logic to handle the rollback.
E.g. make a copy before editing, then track which objects were new → delete those, and which objects existed in the DB but were edited → persist the copies with the old values.
Hi!
We have this registered as an internal challenge / improvement, and I’ve added an upvote on it. I cannot say when it will be implemented yet, but it is definitely interesting for many customer solutions to have such built-in functionality. Mongodb (the underlying database) now have support for such (not previously).
Thanks for the replies Øyvind and Kristian.
@oyvind.byhring Yeah that approach is what we plan to do as well. It’s reliable but just a bit heavy to implement.
@kristian That’s great to hear! Just curious how prioritised the feature is, and if you have an estimation of when it will come out? Would make it easier for us to plan our development as well.
One of my colleagues, Ryan, also asked about this a year ago: Transaction control - #2 by Simona
Hi,
This feature is pretty technical, so no quick turnaround to implement. To be realistic, with the current pipeline for product updates for this fall (very AI-focused), my current guesstimate will be late 2025/early 2026. Note that it is currently still a feature request that needs to be analyzed and designed before further details can be more precise.
So, for the short term I suggest to look for alternative ways to implement or handle such scenarios. For example: Runtime updates and validations until persisting in sequence (reduces risk of failing half-way), a Service that cleans up inconsistencies etc.
Just a quick comment on this one: One persist operates in 1 transaction. So, if 1 of 100 objects in a single persist fails (e.g. violates a constraint), none of the 100 objects will be saved.