Opened 5 years ago
Last modified 12 months ago
#31583 new New feature
Extend deferred unique constraint support to OneToOneField
Description ¶
Support for DEFERRABLE INITIALLY DEFERRED was added in https://code.djangoproject.com/ticket/20581 . It would be great if it could be extended to the implicit Unique constraint generated by OneToOneField
, say, by adding an argument:
OneToOneField(OtherModel, defer=models.Deferrable.DEFERRED)
According to the ticket's flags, the next step(s) to move this issue forward are:
Unknown. The Someday/Maybe triage stage is used to keep track of high-level ideas or long term feature requests.
It could be an issue that's blocked until a future version of Django (if so, Keywords will contain that version number). It could also be an enhancement request that we might consider adding someday to the framework if an excellent patch is submitted.
If you're interested in contributing to the issue, raising your ideas on the Django Forum would be a great place to start.
Change History (5)
comment:1 by , 5 years ago
Triage Stage: | Unreviewed → Someday/Maybe |
---|
comment:2 by , 4 years ago
Cc: | added |
---|
comment:3 by , 3 years ago
Cc: | added |
---|
comment:4 by , 3 years ago
I think it would be quite easy. Here we could pass deferrable
argument based on new_field.defer
value:
https://github.com/django/django/blob/4.0/django/db/backends/base/schema.py#L810
https://github.com/django/django/blob/4.0/django/db/backends/base/schema.py#L1245
comment:5 by , 12 months ago
There is a use case for this, ordering of database rows using a linked list. OneToOne can be used to define the field pointing to the previous row, but the associated constraint needs to be deferred to allow for updates that temporarily violate the constraint while changing the row ordering.
We were able to implement this, but it involved a workaround. Specifically we had to manually delete the constraint created by the OneToOne and then recreate it with deferred in our migrations, then add that constraint to the model definition also.
Not sure we should do that as it seems pretty niche.
I guess an alternative API could be to allow passing a
UniqueConstraint
to theunique
kwarg like we've discussed doing to theField.index
one.e.g.