On Thu, Mar 26, 2009 at 1:22 AM, @@ <ask...@gmail.com> wrote: > Hi, > I run into a strange problem when i changed my code a little and then test > my apps. > In some tests(not the first) i got the error message below: ... > IntegrityError: (1452, 'Cannot add or update a child row: a foreign key > constrai > nt fails (`test_app_o2`.`auth_permission`, CONSTRAINT > `content_type_id_refs_id_7 > 28de91f` FOREIGN KEY (`content_type_id`) REFERENCES `django_content_type` > (`id`) ... > which is really wired, as you can see the cause is: create_permissions got > called and the content_type was not filled with data . However there are > some testcases passed, that means sometimes create_permissions works. > And then i changed the order of INSTALLED_APPS , i put > django.contrib.contenttypes before django.contrib.auth then run the test, > all my testcase passed. > But i still can't figure out why this happens, and only happens in some > testcases.
Ordinarily the order in INSTALLED_APPS _shouldn't_ matter. However, this looks like you're hitting a form of #7052. The problem plays out like this: Certain applications (in particular, contenttypes and auth) dynamically create database content (permissions, content type identifiers, etc) when they are synchronized. When you dump a fixture, those dynamically created content types etc are stored in the fixture. When the test case flushes the database, the application attempts to recreate the dynamic data, and then loads the fixture. If the dynamic data isn't recreated in the same order as it was to create the data in the fixture, you get an error from the database complaining about uniqueness in foreign key constraints. This is because during the process of loading a fixture, the primary keys for the existing dynamic content differs from that in the fixture, so you can end up two identical rows of content but with different primary keys - leading to a constraint problem. By changing the order in INSTALLED_APPS, you are modifying the order in which the dynamic data is recreated; in your case, it appears that by changing the order, you can match the order that already exists in your fixture, and the constraint problem doesn't eventuate. The long term solution here is to fix #7052. In the interim, the solution is to either: 1) Avoid putting dynamic content in your fixtures - this means removing auth and contenttype objects from your fixture. This won't cause any problems unless you are relying upon links to dynamic content objects in your tests. The most common reason for needing such links is using generic relations, but there are others. 2) Generate a new fixture whenever you add an application to your project, or add a model to an application in your project. Obviously, this is fairly fragile as a solution, but it should work. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
