Ecto strange (?) one-to-many validation errors on children

silverdr

I have a one-to-many relation where I – say – add items to cart. Once I add one item it’s fine. When I add another I get:

errors: [id: {"has already been taken", []}]

on the second item, even if it’s not persisted. The whole changeset looks (simplified) like:

#Ecto.Changeset<
  action: :validate,
  changes: %{
    [...]
    items: [
      #Ecto.Changeset<
        action: :insert,
        changes: %{
          description: "gin",
          [...]
        },
        errors: [],
        data: #MyApp.Cart.Item<>,
        valid?: true
      >,
      #Ecto.Changeset<
        action: :insert,
        changes: %{
          description: "tonic",
          [...]
        },
        errors: [id: {"has already been taken", []}],
        data: #MyApp.Cart.Item<>,
        valid?: false
      >
    ],
  },
  errors: [],
  [...]
  valid?: false
>

I “put” the action “validate” on the parent in the changeset like:

changeset = %Cart{}
|> Cart.changeset(add_static_fields(params, socket))
|> Map.put(:action, :validate)

but apparently children have action “insert” in their respective changesets. Since I am not “inserting” the parent anyway, why do the children complain about their “id being taken”? No id’s been assigned yet, or what part of my brain is not working today?

7 comments

#ecto #liveview #form-validation

0 1598 7

2022-08-11 14:10:01 UTC

Showing Posts 1 to 7

Show Best Posts
Show All (oldest first)
Show All (newest first)

al2o3cr

Can you show the code for Item.changeset? I’ve got several questions:

where are the Item changesets getting any value for id?
who is adding that error?
the DB-side uniqueness validations would need to somehow get ahold of an Ecto.Repo; is there anything unusual in Cart.changeset?

Post #1

silverdr

where are the Item changesets getting any value for id?

There’s no explicit assignment. DB sequence assigns it upon creating record. Here the record is not created and the ‘id’ is not in the changeset. OTOH the form does have an id field

  "items" => %{
    "0" => %{
      "description" => "gin",
      "id" => "",
      [...]
    },
    "1" => %{
      "description" => "tonic",
      "id" => "",
      [...]
    }

but values are empty there and as discussed in another thread there should be no need for “scrubbing” them. I might try doing this still manually and see if that helps

who is adding that error?

I take Ecto adds it. No explicit addition from the application’s code

the DB-side uniqueness validations would need to somehow get ahold of an Ecto.Repo; is there anything unusual in Cart.changeset?

I think Ecto adds it before DB has any chance of having a stab at checking. It looks to me like it sees the two (empty) ids and concludes they’re the same before going further: a) the parent record is not inserted, b) there’s no DB activity in the logs, and to answer the question there’s nothing uncommon in the Cart.changeset. Casting attrs, and casting association:

	|> cast_assoc(:items, required: true)

plus some validations but only on the cart data itself

Can you show the code for Item.changeset ?

Sure!

def changeset(%MyApp.Carts.Item{} = item, attrs) do
	item
	|> cast(attrs, [:description, :quantity])
	|> validate_length(:description, [min: 2, max: 30])
	|> validate_required([:description, :quantity])
	|> validate_number(:quantity, [greater_than_or_equal_to: 1, less_than_or_equal_to: 99])
end

Post #2

silverdr

Yes, removing ids from form data helps. Hmm…

Post #3

dodo

Just ran into this problem as well, shouldn’t cast remove any non-permitted params?

Post #4

al2o3cr

This error isn’t coming from the database, it’s from the internals of cast_assoc:

https://github.com/elixir-ecto/ecto/blob/3ee206b63c13272f0d7a5d48c37dbc1045f07ea0/lib/ecto/changeset/relation.ex#L386-L394

Two thoughts on what could be causing this:

that code relies on the value being passed in id params casting to nil if it’s empty. Integers definitely do that, but (for instance) plain strings would not. What type are your ID columns?
Changesets allow any value to be set into action, but depend on specific values like :insert for some behaviors. The original post was setting the action to :validate; does the same issue persist if the action is set to :insert?

Post #5

silverdr

At least in my case I still believe that Ecto does this (adds the error) before anything goes to the DB level. And before doing casts/whatever. Kinda soft-bug it seems

Post #6

dodo

Hi, thank you for the quick reply!

I am using regular auto-incrementing integer ids (bigserial). I set the id of newly created items to -1 in the frontend to avoid nullable types, I just ended up not sending those in the request to fix the issue.

The action field is not set manually, I am using cast_assoc with a has_many relation and on_replace: :delete because the frontend always sends all associations. The error appeared when the action was :update on the root entity and :insert on the associated (has_many) entities, those were preloaded but empty before updating.

I understand that Ecto relies on the id for finding existing entities and proceed depending on the on_replace option, but I thought the id would just be ignored when it does not match any existing entity.

Now that I think about it I actually prefer the existing behavior, it seems safer than just ignoring invalid ids .