Uncertainty about constraint checks during fixture loading

[pascal chambon]

I've encountered this paragraph in docs :

https://docs.djangoproject.com/en/1.9/ref/django-admin/#what-s-a-fixture

Note that the order in which fixture files are processed is undefined. However, all fixture data is installed as a single transaction, so data in one fixture can reference data in another fixture. If the database backend supports row-level constraints, these constraints will be checked at the end of the transaction.

However, from my experience, heavily used DBs like MySQL do not have deferred constraint checking :
​http://stackoverflow.com/a/5014744/345876

So if fixtures are loaded in undefined ordered, tehse references might trigger referential integrity errors on these DB engines.

Are there things I'm missing here, or shouldn't we add a note on this ?

[Tim Graham]

Maybe we can mark this as a duplicate of #15578 which is about revising the "undefined ordering" language?

[pascal chambon]

Hum to me these tickets are more complementary than duplicates, mine was just a doc update, the #15578 seems to deal with an engine that has no "deferred constraint checking" (although i'm not sure that this feature would suffice to solve the OP's problem) but proposes changes in the behaviour of loaddata instead.

Should I bring my notes to the other ticket, so that both aspects (docs & behaviour) get matched whatever the choices made ?

[Tim Graham]

Yes, I think you can add your notes there (or even do some investigation about the actual ordering that's used and submit a patch if you have time). #15578 is a pure documentation ticket too, as far as I can tell (at least, it's component is "Documentation" so no behavior changes are expected to be made to resolve it).