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