Ecto.Repo.update_all/3 does not raise Ecto.StaleEntryError on locked rows
0 reputation · 04 Sept 2022, 09:37 UTC
A schema uses an integer lock column for Ecto optimistic locking, so Repo.update/3 increments the value and raises Ecto.StaleEntryError when the stored lock no longer matches the changeset.
The goal is to determine whether Repo.update_all/3 can overwrite such a row without incrementing lock or surfacing a conflict, and whether that behavior is consistent across Ecto versions and database adapters. Because update_all/3 executes a direct SQL UPDATE and bypasses Ecto.Changeset, validations, callbacks, and optimistic-lock handling, a concurrent bulk update may silently replace data written through a changeset-based path.
This is a design question, not an observed incident. Confirm the exact semantics against the installed Ecto release and adapter before relying on bulk updates in locked tables.
Does Repo.update_all/3 leave the lock column unchanged when updating a locked row? Can a bulk update overwrite a row modified through Repo.update/3 without raising Ecto.StaleEntryError? Should applications avoid update_all/3 on schemas that use optimistic locking?
ecto