Yes, this is absolutely required!
This flow would work, but I’d have to clean all “tags” not referencing “posts” in the DB at the end, which is an operation that could fail on its own and leave us with loose “tags”. Remember that the “tag” in this case, can only exist on two occasions: if a “post” is persisted and if a “post” has errors. It’s almost like a logging mechanism, if I create the log before and there’s nothing worth logging I have to remove it somehow.
BTW, It seems someone else already had this exact same problem: How to not rollback transaction on failed insert because of unique constraint - #8 by benwilson512. I conducted some tests using one of the post’s suggestions and the savepoint feature seems to work without much effort. The only difference is that no additional match on the case was required:
Repo.transaction(fn repo ->
case repo.insert(changeset, mode: :savepoint) do
{:ok, post} ->
IO.inspect(post, label: "POST")
tag
|> Ecto.Changeset.change(%{name: "success"})
|> repo.update!()
{:error, changeset} ->
IO.inspect(changeset, label: "CHANGESET")
tag
|> Ecto.Changeset.change(%{name: "failed"})
|> repo.update!()
end
end)
This returns the tuple with the changeset containing the constraint errors and commits the transaction as expected:
12:31:46.616 [debug] QUERY OK db=1.6ms queue=0.2ms
INSERT INTO "tags" VALUES (DEFAULT) RETURNING "id" []
12:31:46.620 [debug] QUERY OK db=1.5ms queue=0.1ms
INSERT INTO "posts" ("title") VALUES ($1) RETURNING "id" ["123"]
12:31:46.620 [debug] QUERY OK db=0.1ms
begin []
12:31:46.622 [debug] QUERY ERROR db=1.5ms
INSERT INTO "posts" ("title") VALUES ($1) RETURNING "id" ["123"]
CHANGESET: #Ecto.Changeset<
action: :insert,
changes: %{title: "123"},
errors: [
title: {"has already been taken",
[constraint: :unique, constraint_name: "posts_title_index"]}
],
data: #Post<>,
valid?: false
>
12:31:46.624 [debug] QUERY OK db=0.2ms
UPDATE "tags" SET "name" = $1 WHERE "id" = $2 ["failed", 1]
12:31:46.626 [debug] QUERY OK db=1.8ms
commit []
