Hello, When a question of "should Django do A or B here?" comes up, adding a setting to let the user choose is the last resort, because it's really a cop-out, not the default choice.
Django explicitly creates FKs on PostgreSQL as DEFERRABLE INITIALLY DEFERRED in order not to check constraints until the end of a transaction. Certainly it does that for a reason -- although I'm not sure which one, perhaps ensuring fixture data can be loaded in arbitrary order? The thought process here should be: 1. For what reason does Django do that? Does this reason also apply, or still apply, to the situation where you disagree with Django's behavior? 2. What's going to break if we make this change? We aren't going to provide an option that's incompatible with other documented features. 3. Is there a good reason to let the user pick one behavior or the other? If so, how are we going to explain how to choose the adequate behavior for a given use case? 4. Given the above, what should be implemented? I never thought about deferred constraints check when I added support for savepoints to all built-in backends. Previously one PostgreSQL had support for savepoints and it was minimal. My gut feeling is that it's a decent idea to check integrity constraints in atomic(savepoint=True), assuming this doesn't have horrific consequences for performance. Note that savepoint=True is the default for users, but that Django uses savepoint=False internally whenever possible for performance. -- Aymeric. 2015-12-21 4:24 GMT+01:00 Артём Клименко <[email protected]>: > I opened this ticket https://code.djangoproject.com/ticket/25955 > > The last proposal for the improvement > https://code.djangoproject.com/ticket/25955#comment:5 > add parameter in OPTIONS > > DATABASES = { > 'default': { > 'ENGINE': 'django.db.backends.postgresql_psycopg2', > # ... > 'OPTIONS': { > 'savepoint_check_constraints': True > } > }, > } > > > https://code.djangoproject.com/attachment/ticket/25955/django_master_v2.patch > > -- > 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/f1d474af-1191-4110-b664-2561d9477631%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/f1d474af-1191-4110-b664-2561d9477631%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Aymeric. -- 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/CANE-7mX02TM8E%3Dc%2BbUny2s%2BAT%3Dd26%2BumvgpDRd_%3D0CCODbY5vg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
