A simple patch to solve MySQL constrain problem while dumpdata.

[bear330]

The ​http://www.djangoproject.com/documentation/django-admin/#loaddata-fixture-fixture documentation mentioned:

MySQL doesn’t provide a mechanism to defer checking of row constraints until a transaction is committed.

This problem can be solved by a simple modification to one line code in django.db.models.loading.py:

The original code:
model_dict = self.app_models.setdefault(app_label, {})

Patched code:
model_dict = self.app_models.setdefault(app_label, SortedDict())

This modification make us to define the table sequence of app models by our will.
We know the constrain between models, SortedDict make app_models store models as we defined.
This will be helpful while dumpdata and some other problems.

Thanks.

[Russell Keith-Magee]

This would in no way solve the problem that exists with MySQL. The problem isn't cross-model dependencies, it's cross-instance dependencies. i.e., Model instance A refers to model instance B, but instance B has not yet been created. A and B might be of the same class (in which case this patch would do nothing). There could be circular relationships in the data (in which case there is no way to order your models to remove the problem). It isn't just a matter of finding the right order in which to serialize things - we need the database backend to relax constraint checking until we can guarantee that all the pieces are in place.

[anonymous]

Replying to russellm:

This would in no way solve the problem that exists with MySQL. The problem isn't cross-model dependencies, it's cross-instance dependencies.

Ok, I understood! But make the code from:

model_dict = self.app_models.setdefault(app_label, {})

to

model_dict = self.app_models.setdefault(app_label, SortedDict())

really solve some problem while I dump data or other situations.

Using SortedDict makes get_models() reliable in many respects. And I can simply solve the MySQL problem if I just have a cross-model dependencies problem.

This just change one line... (ok, and additional import statement).

Thanks.

[bear330]

By the way, I create this ticket because I really encounter this problem, I have a model A which depends on model B (so, I define B before A). When I dumpdata, the dump sequence is not the same as I defined. I finally found it can be solved by this small modification.

And this modification also solved some bugs in my old code calling get_models() (I process models before some operations, the sequence of models is very important to me.).

I believe this small modification will make get_models() more reliable and no side effect to the existed code.

[Brian Rosner]

Just because you encountered a problem doesn't mean that it is a problem with Django. You made the assumption that the problem you are seeing was the note given in the documentation when in fact it is not.

Please search Trac before submitting a ticket. This has been reported before and is not just related to dumpdata. Please see #4193.

[bear330]

Replying to brosner:

Just because you encountered a problem doesn't mean that it is a problem with Django. You made the assumption that the problem you are seeing was the note given in the documentation when in fact it is not.

Please search Trac before submitting a ticket. This has been reported before and is not just related to dumpdata. Please see #4193.

I am so sorry about that, this is because I simply think this problem is related to this MySQL problem. The title of this ticket is wrong.

Because of this wrong first impressions, I don't find #4193 though I searched ticket system with 'dumpdata constrain' keywords.

Thanks for your help.