How to make Ecto.Multi link multiple inserts where subsequent inserts require the primary key of the first operation?

Edit: I’d use @idi527’s example as it’s much more idiomatic.

Here’s a contrived example that should give you the general idea.

Ecto.Multi.new
|> Ecto.Multi.run(:user, fn _ ->
  create_user(user_params)
end)
|> Ecto.Multi.run(:email, fn %{user: user} ->
  create_email(user, email_params)
end)
|> Repo.transaction()

When you use Multi.run, you tag the operation using the second argument. For example, the |> Ecto.Multi.run(:user ... makes the result of create_user available under the :user key in the next the function.

create_user!(user_params) and create_email!(user, email_params) would need to return {:ok, resource} or {:error, reason}, so these are unlikely to be “bang” operations.

And the last |> Repo.insert() would need to be replaced with Repo.transaction().

@fireproofsocks note that Multi.runs are not automatically rolled back on errors, I’d probably use inserts instead. Modifying @abitdodgy’s example:

alias Ecto.Multi

Multi.new()
|> Multi.insert(:user, User.changeset(%User{}, user_params) end)
|> Multi.insert(:email, fn %{user: %User{id: user_id}} ->
  Email.changeset(%Email{author_id: user_id}, email_params)
end)
|> Repo.transaction()

Good catch. I just cooked that example up!

Are you sure? A Multi is executed in a transaction and for as long as the command in a Multi.run does only cause side effects to the db and nothing else it should just be rolled back like any other db operation, which happened in that transaction. I‘ve even some places in my projects, where Multis are effectively nested, as the inner multis are executed in named functions which a outer multi composes.

Precisely, DB actions are rolled back because of a transaction, but run/3,5 is often used to perform non-db actions that need to be run only if the DB succeeds, however there is not version of run/? that allows you to pass both a ‘do’ and an ‘undo’ function, which would be a huge help personally. as right now you have to check it ‘after’ running Repo.transaction, thus meaning the actions of the multi have to ‘leak’ out of where they are defined. We could really use a run/4;8 as well to support both a do and undo…

How would you ensure that the cleanup doesn’t fail? For the database part it’s a guarantee of the database, but for other side effects ecto cannot do that. Ecto.Multi.run exist because before ecto 3 you could only pass a callback to Ecto.Multi.run and it’s the only way to compose function which do their own database operations.

That would be on the onus of the one writing their own cleanup function. Some things are just not undoable of course, thus keep using the currently existing functions for those.

That’s exactly why Ecto.Multi is not the tool to use imo. You’re no longer orchestrating database operations within a transaction, but arbitrary operations. This is a different requirement, which should be handled by a more appropriate tool like sage.

Well in my case I’m orchestrating things that need to stay in sync between 2 different databases and an LDAP system, where if any of them fail I can and do need to roll them all back. It’s still a database transaction, just spread across 3 databases (one of which is not transactional, LDAP, so have to roll it back manually)… ^.^;

What is this sage thing and most curiously how would it handle this?

https://github.com/Nebo15/sage