benonymus
Unexpected Multi transaction result? Different value in Multi result compared to db value
Hey there,
I have the relatively simple Multi:
def set_user_team_is_default(%UserTeam{user_id: user_id, team_id: team_id}) do
Multi.new()
|> Multi.update_all(
:set_other_teams_to_non_default,
from(ut in UserTeam, where: ut.user_id == ^user_id and ut.is_default == true),
set: [is_default: false]
)
|> Multi.update(
:set_to_default,
# getting the user_team here or not getting and using the received one results in the same
UserTeam.changeset(get_user_team(user_id, team_id), %{is_default: true})
)
|> Repo.transaction()
end
It is used to set every user_team(that is default) is_default to false and then set one as default.
Now the following unexpected thing happened:
-
User opened the page in browser A and then opened the same page in browser B at the same time.
-
User selects team A as default in browser A - works as expected
-
User selects same team A as default in browser B - user ends up without a default team.
Why does this happen?
The result of the multi when this occurs is this:
{:ok,
%{
set_other_teams_to_non_default: {1, nil},
set_to_default: %XXX.UsersTeams.UserTeam{
__meta__: #Ecto.Schema.Metadata<:loaded, "users_teams">,
id: 3,
inserted_at: ~N[2022-03-01 09:28:23],
is_default: true,
role: :admin,
status: :active,
team: #Ecto.Association.NotLoaded<association :team is not loaded>,
team_id: 3,
updated_at: ~N[2022-04-07 05:54:59],
user: #Ecto.Association.NotLoaded<association :user is not loaded>,
user_id: 2
}
}}
As you see in the result of the multi is_default is true for the user_team.
But!
If I fetch the user_team right after the multi it shows this:
%XXX.UsersTeams.UserTeam{
__meta__: #Ecto.Schema.Metadata<:loaded, "users_teams">,
id: 3,
inserted_at: ~N[2022-03-01 09:28:23],
is_default: false,
role: :admin,
status: :active,
team: #Ecto.Association.NotLoaded<association :team is not loaded>,
team_id: 3,
updated_at: ~N[2022-04-07 05:54:59],
user: #Ecto.Association.NotLoaded<association :user is not loaded>,
user_id: 2
}
While the multi returns that is_default is true, in the database it is false!
According to the multi docs: Ecto.Multi — Ecto v3.14.0
If a multi is valid (i.e. all the changesets in it are valid), all operations will be executed in the order they were added.
Can someone explain as to why does this happen?
Fixing it is easy(patter match on the incoming user_team, if is_default: true ignore it), I am not asking for that, I want to understand why does it happen.
Marked As Solved
benonymus
Something interesting:
If I change step 2 to be like this:
|> Multi.update(:set_to_default, fn _ ->
UserTeam.changeset(get_user_team(user_id, team_id), %{is_default: true})
end)
It works as expected, always.
Also Liked
LostKobrakai
Multi.update / Repo.update is considered a noop (no query to the db) if there are no changes on the schema. If you have a user_team, which is the default, and then add a change of making it the default, then this is such a case of “no change present”. So you might not always get two queries here. It might be just one.
This doesn’t set “other” teams to not be defaults. This unsets all default teams not matter if it’s the current one or not.
What I can’t understand is why doing get_user_team(user_id, team_id) in the second step didn’t help resolve issues. Nothing should be a default, so making the current userteam the default should always work.
LostKobrakai
Step 2 only sets the default if the base data for the changeset have the user_team not be the default already (unless you use force_change). Otherwise the changeset sees a value to be set to the value already on the schema, which makes step 2 a noop. Not sure if that’s happening here / for you though.
LostKobrakai
Yes. I didn’t notice that. Without the anonymous function the code runs when defining the step, rather then when executing the step within the transaction.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








