Ecto.Multi is a data structure that allows grouping multiple Repo operations together.

Ecto.Multi makes it possible to pack operations that should be performed together (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 or will help to identify the place of failure in case it occurs.

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.

insert/4, update/4 and delete/4 also accept a function which receives the changes so far and returns a changeset. This allows introspection and use of database generated values, such as ids, from previous steps. However when using changesets wrapped in functions the changeset can not be validated prior to starting the transaction.

Run

Multi allows you to run arbitrary functions as part of your transaction via the run/3 and run/5. Those functions will receive changes so far as the first argument and have to return {:ok, value} or {:error, value} as their 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. We define a function creating the Multi structure probably in some sort of service layer:

defmodule Service do
  alias Ecto.Multi
  import Ecto

  def password_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, assoc(account, :sessions))
  end
end

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

Repo.transaction(Service.password_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 = Service.password_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