The only generic way to check the constraints is to run through all tables and their constraints. The constraint check itself is a check that a matching row in a foreign table exists for each row of the checked table. This means that the check could take hours on large databases. In addition the check isn't safe against concurrency issues. I'm afraid that if we have a flag for this for atomic(), then users are going to think it is a good idea to run the check just in case.
We could add a documented API to check wanted models for foreign key constraint violations (.check_constraints(Model1, Model2) would be a likely API). Then lets just document that depending on the database this check can be slow. On some databases we can get away with SET CONSTRAINTS IMMEDIATE [http://www.postgresql.org/docs/9.1/static/sql-set-constraints.html], which should be fast. I do think DEFERRABLE INITIALLY IMMEDIATE constraints would make a lot of sense for what Django is doing with the constraints, that is we want to keep the constraints in check except in special cases. Unfortunately I can't see an easy way to switch constraints to INITIALLY IMMEDIATE mode due to backwards compat and migrations issues. - Anssi On Mon, Dec 21, 2015 at 4:41 PM, Shai Berger <[email protected]> wrote: > While expensive operations may be unsuitable for general consumption, this > kind of validation may be useful in special cases and offline jobs, notably > in "data" migrations. So I think we should consider supporting them via an > argument to atomic(). > > Be that as it may, so long as we do not plan to change global behavior, we > should fix the documentation. The current text and example code strongly > imply that FKs are checked at the end of atomic blocks, even though they > manage to avoid saying it explicitly. > > Shai. > > On 21 בדצמבר 2015 14:17:53 GMT+02:00, Aymeric Augustin > <[email protected]> wrote: >> >> 2015-12-21 13:12 GMT+01:00 Anssi Kääriäinen <[email protected]>: >>> >>> The check_constraints operation is extremely expensive, and not suitable >>> for use at the end of savepoints. >> >> >> Ah. Too bad! >> >> -- >> Aymeric. > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/F0A7E950-24FE-457C-877D-905EA3E9AA65%40platonix.com. > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALMtK1FENw4gKKYhN2PS2ZFxisUAt_kzDV9wKD%2B9fxmQo9h3cg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
