Unexpected Multi transaction result? Different value in Multi result compared to db value

Questions / Help
, , ,
1

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:

  1. User opened the page in browser A and then opened the same page in browser B at the same time.

  2. User selects team A as default in browser A - works as expected

  3. 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.11.1

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.

2

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.

1 Like
3

Correct, step 1 will set all default teams to not default, even the sent one if it is the default(in the actual code the default false setting is a reusable multi piece, I don’t think step 1 should care about if the user_team you are sending is a default or not).

Step 2 tries to set the sent one as the default(which I expected to be set as default even if it was set to false in step one, as you said.)

4

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.

1 Like
5

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.

6

If I do this(back to the original):

    |> Multi.update(
      :set_to_default,
      UserTeam.changeset(get_user_team(user_id, team_id) |> IO.inspect(), %{is_default: true})
    )

In the output it shows the is_default as true.

%XXX.UsersTeams.UserTeam{
  __meta__: #Ecto.Schema.Metadata<:loaded, "users_teams">,
  id: 157,
  inserted_at: ~N[2022-03-18 08:20:38],
  is_default: true,
  role: :owner,
  status: :active,
  team: #Ecto.Association.NotLoaded<association :team is not loaded>,
  team_id: 76,
  updated_at: ~N[2022-04-07 09:17:03],
  user: #Ecto.Association.NotLoaded<association :user is not loaded>,
  user_id: 2
}

So it will be a noop as you said.

But then does that mean that this get_user_team runs outside the transaction?

Edit: Looks like yes, looking at it a bit more it makes sense. If you rely on changes in the transaction, that part needs to run IN the transaction in the fn. The docs more or less show this, but don’t say it explicitly.
https://hexdocs.pm/ecto/Ecto.Multi.html#update/4-example

Thanks @LostKobrakai for facilitating the thinking process!

7

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.

1 Like