#33137: Decouple Field.unique from select_related
-------------------------------------+-------------------------------------
Reporter: Markus Holtermann | Owner: nobody
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
-------------------------------------+-------------------------------------
Description changed by Markus Holtermann:
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 <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.6f65065bad393b0e18d4e9f5003cb96d%40djangoproject.com.
