On Thursday 31 December 2015 06:31:40 Gavin Wahl wrote:
> I understand that a database is invalid or invalid as a whole, which is why
> you don't need to check constraints until transaction commit (when the
> transaction becomes visible to the world). Why do you want to bundle
> constraint checking
I understand that a database is invalid or invalid as a whole, which is why
you don't need to check constraints until transaction commit (when the
transaction becomes visible to the world). Why do you want to bundle
constraint checking with a savepoint release though? They seem logically
unrelated.
Hi,
On Tuesday 29 December 2015 19:40:44 Gavin Wahl wrote:
> What does it even mean for constraints to be checked at savepoint commit? I
> would expect this to not cause any errors:
>
> with atomic():
> # insert invalid fk
> with atomic(check_deferred_constraints=True):
>
What does it even mean for constraints to be checked at savepoint commit? I
would expect this to not cause any errors:
with atomic():
# insert invalid fk
with atomic(check_deferred_constraints=True):
# do stuff that doesn't invalidate any contraints
# delet
On Tuesday, December 22, 2015 at 1:20:23 AM UTC+2, Shai Berger wrote:
>
> > 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
> > th
On Monday 21 December 2015 19:42:22 Anssi Kääriäinen wrote:
> 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 th
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 ch
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
2015-12-21 13:12 GMT+01:00 Anssi Kääriäinen :
> The check_constraints operation is extremely expensive, and not suitable
> for use at the end of savepoints.
Ah. Too bad!
--
Aymeric.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributio
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 unt
The check_constraints operation is extremely expensive, and not suitable
for use at the end of savepoints.
The reason why we use deferred constraints by default is mostly historical.
We do need deferred constraints for fixture loading, and applications might
rely on current implementation, but we
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',
# ...
'
12 matches
Mail list logo
