Add support for natural key serialization
|Reported by:||Jay Hargis||Owned by:||nobody|
|Severity:||Normal||Keywords:||auth_permission auth_content fixture import|
|Cc:||daevaorn@…, bsn.dev@…, greg@…, Manuel Saelices, russ.amos@…, winhamwr@…, Carl Meyer, Michael Manfre, sanfordarmstrong@…, juan@…, simon@…, kmike84@…, chris@…, jashugan@…, robmadole@…||Triage Stage:||Accepted|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
If you perform a fixture dump on auth, so as to have users in your test database to perform unit testing. When you try to run the test server, telling it to load the auth fixture, it *can fail. I turned the logging in PostgreSQL to log every query, and found that it was a foreign key violation that was causing the failure. Further investigation seemed to indicate that since I had altered data in auth_permission and django_content_type by hand, resulting in the sequence of primary keys becoming non sequential, this was causing the problem.
When these tables are rebuilt during test db creation, the id column of the rows do not end up with the same id's as they did in the database which created the fixture. I don't know if this is related, but as far as I could tell it was simply a matter of the id's in these two tables not being 100% sequential. I ended up dumping all the data out, then creating the database and repopulating it in a linear fashion (with respect specifically to those two tables). This fixed the problem and the test server happily created and populated those tables.
If you never alter these tables by hand, the id's should always remain sequential and this problem will not occur.
Change History (49)
comment:1 follow-ups: 5 31 Changed 8 years ago by
|Patch needs improvement:||unset|
|Triage Stage:||Unreviewed → Accepted|
comment:41 Changed 7 months ago by
|Summary:||auth fixture fails to import when running test server → Add support for natural key serialization|
|Type:||→ New feature|