Ecto.Multi is a data structure for grouping multiple Repo operations.

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 the run/3 and run/5. This is very useful when an operation depends on the value of a previous operation. For this reason, the function given as callback to run/3 and run/5 will receive all changes performed by the multi so far as a map in the first 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:

defmodule PasswordManager do
  alias Ecto.Multi

  def reset(account, params) do
    Multi.new
    |> Multi.update(:account, Account.password_reset_changeset(account, params))
    |> Multi.insert(:log, Log.password_reset_changeset(account, params))
    |> Multi.delete_all(:sessions, Ecto.assoc(account, :sessions))
  end
end

We can later execute it in the integration layer using Repo:

Repo.transaction(PasswordManager.reset(account, params))

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

case result do
  {: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" do
  account = %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:
  assert account_changeset.valid?
  assert log_changeset.valid?
  assert inspect(query) == "#Ecto.Query<from a in Session>"
end