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

Questions / Help
,
#1

A fairly simple use-case: a user has one or more email addresses, stored in the database in 2 separate tables (users, emails) such that the emails table has a foreign key for user_id. (In reality, my use case is more complex, but this illustrates the problem).

Ecto.Multi lets us create a single transaction for adding both the user record and an email record, and we can rollback if either one of those operations fail. Iā€™m looking at the docs for the run/3 and run/5 functions https://hexdocs.pm/ecto/Ecto.Multi.html#run/3 but I canā€™t figure out how these are supposed to be used. From the docs, Iā€™m not at all clear on what value the run function is supposed to return or how that gets ingested by the next operation.

I know I could (sometimes) do this with a single insert operation by leveraging the relationships defined in the schema, but Iā€™m more interested in the principle of the thing.

Thanks as always!

2 Likes
#2

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.

4 Likes
#3

:wave:

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()
12 Likes
Ecto.Multi multiple inserts/updates with primary key of first insert
#4

Good catch. I just cooked that example up!

#5

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.

4 Likes
#6

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ā€¦

2 Likes
#7

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.

#8

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. :slight_smile:

#9

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.

#10

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?

#11
3 Likes
#12

@LostKobrakai Awesome, thanks for that! It seems the readme makes clear everything Iā€™d need to do and how it works except for one big thing, the multiple database calls across the multiple databases do they run in a singular DB transaction each across them all or are they on a call-by-call basis only (I.E. no DB transactions across the entire Sage call)? I.E. does it start up an Ecto.Repo.transaction for all calls to the given database (thus those calls need to be handled inside that transaction) on the first call of a given repoā€™s transaction orā€¦)? How does it handle the transactions failing in any order and handling the rollback then?

#13

Iā€™ve never used it by myself, so Iā€™m not sure how integrated it is with ecto. But maybe the possibility to arbitrarily nest transactions in ecto can be of aid for that.

#14

That depends on the database itself, but thatā€™s not the issue here, the issue is keeping two transactions active and in sync across two different databases, I.E. two different Repo modules.

#15

I was thinking about something like this, but as I said Iā€™ve no clue if it would really work:

Repo1.transaction(fn -> 
  Repo2.transaction(fn -> 
    Sage.execute(ā€¦)
  end)
end)

Maybe there are also better ways to do that.

2 Likes