[Django] #33137: Decouple Field.unique from select_related
Django
-------------------------------------+-------------------------------------
Reporter: Markus | Owner: nobody
Holtermann |
Type: New | Status: new
feature |
Component: Database | Version:
layer (models, ORM) |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
When inheriting from a `OneToOneField` that automatically adds additional
constraints to a model, the object-level relation might be a one-to-one
relation, while the underlying implementation is still a many-to-one.
Let's say you have two models `A` and `B` where `A.rel =
MyOneToOneField(B)` and `A.deleted = BooleanField()`. In a regular
`OneToOneField` there would now be a unique index on `A.rel`. However, by
adding a unique constraint to `A._meta.constraints` over `rel` with a
condition on `deleted=False`, `rel` only needs to be unique among the
"undeleted" objects. Doing so is possible by forcing
`MyOneToOneField.unique=False` (otherwise migrations create a constraint).
However, this will mean, `SQLCompiler.get_related_selections()` fails when
trying to do `B.objects.select_related("a")`, since `a` is not a valid
field. That is because
`SQLCompiler.get_related_selections._get_field_choices()` uses
`f.field.unique` instead of `(f.field.many_to_one or f.field.one_to_one)`,
I think. Because, essentially, `opts.related_objects` is build based on
those `(many|one)_to_(many|one)` field attributes.
--
Ticket URL: <https://code.djangoproject.com/ticket/33137>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Database layer | Version:
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Old description:
> When inheriting from a `OneToOneField` that automatically adds additional
> constraints to a model, the object-level relation might be a one-to-one
> relation, while the underlying implementation is still a many-to-one.
>
> Let's say you have two models `A` and `B` where `A.rel =
> MyOneToOneField(B)` and `A.deleted = BooleanField()`. In a regular
> `OneToOneField` there would now be a unique index on `A.rel`. However, by
> adding a unique constraint to `A._meta.constraints` over `rel` with a
> condition on `deleted=False`, `rel` only needs to be unique among the
> "undeleted" objects. Doing so is possible by forcing
> `MyOneToOneField.unique=False` (otherwise migrations create a
> constraint). However, this will mean,
> `SQLCompiler.get_related_selections()` fails when trying to do
> `B.objects.select_related("a")`, since `a` is not a valid field. That is
> because `SQLCompiler.get_related_selections._get_field_choices()` uses
> `f.field.unique` instead of `(f.field.many_to_one or
> f.field.one_to_one)`, I think. Because, essentially,
> `opts.related_objects` is build based on those `(many|one)_to_(many|one)`
> field attributes.
New description:
When inheriting from a `OneToOneField` that automatically adds additional
constraints to a model, the object-level relation might be a one-to-one
relation, while the underlying implementation is still a many-to-one.
Let's say you have two models `A` and `B` where `A.rel =
MyOneToOneField(B)` and `A.deleted = BooleanField()`. In a regular
`OneToOneField` there would now be a unique index on `A.rel`. However, by
adding a unique constraint to `A._meta.constraints` over `rel` with a
condition on `deleted=False`, `rel` only needs to be unique among the
"undeleted" objects. Doing so is possible by forcing
`MyOneToOneField.unique=False` (otherwise migrations create a constraint).
However, this will mean, `SQLCompiler.get_related_selections()` fails when
trying to do `B.objects.select_related("a")`, since `a` is not a valid
field. That is because
`SQLCompiler.get_related_selections._get_field_choices()` uses
`f.field.unique` instead of `(f.field.many_to_one or f.field.one_to_one)`,
I think. Because, essentially, `opts.related_objects` is build based on
those `(many|one)_to_(many|one)` field attributes.
I think, what would fix the behavior, could be something like this:
{{{#!python
class SQLCompiler:
def get_related_selections(self, select, opts=None, root_alias=None,
cur_depth=1,
requested=None, restricted=None):
def _get_field_choices():
direct_choices = (f.name for f in opts.fields if
f.is_relation)
reverse_choices = (
f.field.related_query_name()
for f in opts.related_objects if (f.field.many_to_one or
f.field.one_to_one)
)
return chain(direct_choices, reverse_choices,
self.query._filtered_relations)
}}}
--
--
Ticket URL: <https://code.djangoproject.com/ticket/33137#comment:1>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Database layer | Version:
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Simon Charette (added)
* stage: Unreviewed => Accepted
Comment:
This use case looks very similar to the [https://github.com/akaariai
/django-reverse-unique django-reverse-unique] project by Anssi which
didn't require any adjustments to the ORM and properly supported
`select_related`.
{{{#!python
class A(models.Model):
b = models.ForeignKey('B')
deleted = models.BooleanField()
class Meta:
constraints = [
UniqueConstraint(fields=['b'], condition=Q(deleted=False)),
]
class B(models.Model):
a = ReverseUnique(A, filter=Q(deleted=False))
}}}
I assume you're trying to create a subclass of `OneToOneField` that allows
specifying a `condition` and avoids having to add all of this boilerplate?
{{{#!python
class A(models.Model):
b = ConditionalOneToOne('B', condition=Q(deleted=False))
deleted = models.BooleanField()
class B(models.Model):
pass
}}}
In all cases I'm not against changing the code to use the
[https://docs.djangoproject.com/en/3.2/ref/models/fields/#attributes-for-
fields-with-relations documented] `(many|one)_to_(many|one)` attributes
instead of `unique` assuming we write a proper regression tests for them.
--
Ticket URL: <https://code.djangoproject.com/ticket/33137#comment:2>
Django
-------------------------------------+-------------------------------------
Component: Database layer | Version:
(models, ORM) |
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => needsinfo
Comment:
I'm not sure how actionable this ticket is anymore. The proposed change to
`_get_field_choices` won't actually solve anything as this function is
only used to provide a more helpful error message when passing an invalid
value to `select_related`.
Without providing an implementation that is known to be faulty it's hard
to understand which adjustments should even be made as
[https://github.com/akaariai/django-reverse-
unique/blob/3425e10dccd0ac01469500e47bae66b1999c4a8e/reverse_unique/fields.py#L23-L34
there are examples in the wild] of other ''to one'' fields working
properly by subclassing `ForeignObject` directly.
Closing as ''needsinfo'' pending a demonstration of an implementation that
is problematic. Hopefully documenting `ForeignObject` will make it easier
to write proper implementation for this (#27617).
--
Ticket URL: <https://code.djangoproject.com/ticket/33137#comment:3>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: closed
Component: Database layer | Version:
(models, ORM) |
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* stage: Accepted => Unreviewed
--
Ticket URL: <https://code.djangoproject.com/ticket/33137#comment:4>