How to safely handle related database operations with Ecto Multi

Sometimes you need to do some database operations at once. A simple example: User-A transfers money to User-B. Updating just one balance at the time creates a risk of data desynchronization. What if the first DB operation goes well but updating the second user’s data fails? Sounds like a hard to catch vulnerability.
Fortunately, the IT environment knows the solution. Transaction processing divides the problem into smaller chunks. Every operation is considered separately, but all of them must succeed to apply changes. In that case, User-A won't lose money if the operation of updating User-B balance fails.
Let’s take a look at the code:
Ecto.Multi.new()
|>Ecto.Multi.update(:payer, payer_changeset)
|>Ecto.Multi.update(:reciever, reciever_changeset)
|>Repo.transaction()
Atom argument - in update function - is just the name of the operation. It could be anything that is unique among these actions.
Of course, it would be also nice to handle result:
In case of success there will be returned tuple with :ok atom and instead of the updated structure as the second variable, you can expect the map with all updated structures.
Failure brings some helpful information too – like which operation failed (returns its unique atom), what is the failed value, and what has been changed so far (however not applied).
More about Ecto.Multi: https://hexdocs.pm/ecto/Ecto.Multi.html
Related posts
Dive deeper into this topic with these related posts
You might also like
Discover more content from this category
Today's Advent of Code puzzle inspired me to create this TIL. It may sound trivial, but in fact, it's tricky if you are unfamiliar with the nuances of guards' functioning.
Pattern-matching is one of the finest elixir-lang features. Whoever knows the power of this tool once, will want to use it forever.