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

Questions / Help
, ,
1

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?

2

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?
3
  • 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
4

Yes, removing ids from form data helps. Hmm… :thinking:

5

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

6

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

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?
7

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

8

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