In this post I will explain the issue that can happen during the importing django fixture files into testing database.
Django fixture files enable developer to prepare testing data. We usually put in those files data that is static and essential for data model. For example, list of countries.
The problem is that developer needs to put by hand id fields that must be unique and sometimes also present in other fixture file (related data).
Some context. In the early development, you have several developers working on the feature. They install database on their development machine. Now we have one testing database, and several development databases.
Developer imports other fixture files and creates fixture files related with his features. Now it needs to include his fixtures to source control. The easiest way is to use django command, dumpdata which dumps whole database model. His fixture files contain already imported data from other developers.
Development process continues, which means that data will be added to developer local databases.
It is time for another fixture dump, and import of that dump fails on testing databases.
The reason is that ids in fixture files from several developers are not in sync. Quick and dirty solution is to drop the database. Which is maybe applicable at the early stage of development and on test database. But when we have production data, dropping the database is not the solution.
Solution? All developers should import (and resolve any conflicts using plain sql) fixture files from version control into their local development database before they do dumpdata with new fixture files.
In that way, version control becomes central point for all database fixture files.by