IntegrityError on loaddata restore into non-empty database with existing primary keys
0 reputation · 14 Feb 2020, 08:26 UTC
Restoring fixtures without flushing the target database
When using dumpdata to export a Django project's data and loaddata to restore it, the default behavior inserts fixture rows without removing existing rows in the target database. This design leads to primary-key collisions or unique-constraint violations if the destination already contains rows with the same identifiers. The fixture format also omits database-specific sequence state, so auto-increment counters are not reset, causing subsequent INSERT statements to generate conflicting IDs even after a seemingly successful load.
The goal is to understand the exact failure modes when loaddata encounters pre-existing data across supported backends (PostgreSQL, MySQL, SQLite) in Django 4.2–5.x, and whether any built-in option or transaction wrapper can make the operation idempotent without a full flush.
- Does
loaddata --ignoreor any other flag suppressIntegrityErrorfor duplicate primary keys while still loading non-conflicting rows? - How do sequence/auto-increment values behave after a partial fixture load that aborts mid-transaction on PostgreSQL versus MySQL?
- Is there a documented pattern to verify that all expected objects exist and no orphaned sequence state remains after a restore into a non-empty database?
django