Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#6410 closed (duplicate)

A simple patch to solve MySQL constrain problem while dumpdata.

Reported by: bear330 Owned by: nobody
Component: Core (Other) Version: master
Severity: Keywords: dumpdata constrain
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

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.

Change History (5)

comment:1 follow-up: Changed 8 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

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.

comment:2 in reply to: ↑ 1 ; follow-up: Changed 8 years ago by anonymous

  • Resolution invalid deleted
  • Status changed from closed to reopened

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.

comment:3 in reply to: ↑ 2 Changed 8 years ago by 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.

comment:4 follow-up: Changed 8 years ago by brosner

  • Resolution set to duplicate
  • Status changed from reopened to closed

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.

comment:5 in reply to: ↑ 4 Changed 8 years ago by 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.

Note: See TracTickets for help on using tickets.
Back to Top