Ecto.Multi makes it possible to pack operations that should be
performed in a single database transaction and gives a way to introspect
the queued operations without actually performing them. Each operation
is given a name that is unique and will identify its result in case of
success or failure.

All operations will be executed in the order they were added.

The Ecto.Multi structure should be considered opaque. You can use
%Ecto.Multi{} to pattern match the type, but accessing fields or
directly modifying them is not advised.

Ecto.Multi.to_list/1 returns a canonical representation of the
structure that can be used for introspection.

Changesets

If multi contains operations that accept changesets (like insert/4,
update/4 or delete/4) they will be checked before starting the
transaction. If any changeset has errors, the transaction won’t even
be started and the error will be immediately returned.

Run

Multi allows you to run arbitrary functions as part of your transaction
via run/3 and run/5. This is especially useful when an operation
depends on the value of a previous operation. For this reason, the
function given as a callback to run/3 and run/5 will receive the repo
as the first argument, and all changes performed by the multi so far as a
map for the second argument.

The function given to run must return {:ok, value} or {:error, value}
as its result. Returning an error will abort any further operations
and make the whole multi fail.

Example

Let’s look at an example definition and usage. The use case we’ll be
looking into is resetting a password. We need to update the account
with proper information, log the request and remove all current sessions:

By pattern matching on the result we can differentiate different conditions:

caseresultdo{:ok,%{account:account,log:log,sessions:sessions}}-># Operation was successful, we can access results (exactly the same# we would get from running corresponding Repo functions) under keys# we used for naming the operations.{:error,failed_operation,failed_value,changes_so_far}-># One of the operations failed. We can access the operation's failure# value (like changeset for operations on changesets) to prepare a# proper response. We also get access to the results of any operations# that succeeded before the indicated operation failed. However, any# successful operations would have been rolled back.end

We can also easily unit test our transaction without actually running it.
Since changesets can use in-memory-data, we can use an account that is
constructed in memory as well (without persisting it to the database):

test"dry run password reset"doaccount=%Account{password:"letmein"}multi=PasswordManager.reset(account,params)assert[{:account,{:update,account_changeset,[]}},{:log,{:insert,log_changeset,[]}},{:sessions,{:delete_all,query,[]}}]=Ecto.Multi.to_list(multi)# We can introspect changesets and query to see if everything# is as expected, for example:assertaccount_changeset.valid?assertlog_changeset.valid?assertinspect(query)=="#Ecto.Query<from a in Session>"end

The name of each operation does not have to be an atom. This can be particularly
useful when you wish to update a collection of changesets at once, and track their
errors individually:

This function is useful when the multi to be merged requires information
from the original multi. Hence the second argument is an anonymous function
that receives the multi changes so far. The anonymous function must return
another multi.

Merges a multi returned dynamically by calling module and function with args.

Similar to merge/2, but allows to pass module name, function and arguments.
The function should return an Ecto.Multi, and receives changes so far
as the first argument (prepended to those passed in the call to the function).

Similar to run/3, but allows to pass module name, function and arguments.
The function should return either {:ok, value} or {:error, value}, and
receives the repo as the first argument, and the changes so far as the
second argument (prepended to those passed in the call to the function).