[Django] #27710: foreign key _id optimisation leads to incorrect descriptor value
Django
-----------------------------------------+------------------------
Reporter: Will Hardy | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.10
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
A common optimisation (also recommended in the docs:
https://docs.djangoproject.com/en/1.8/topics/db/optimization/#use-foreign-
key-values-directly) is to use `MyModel.relatedfield_id = 5` for setting a
foreign key, when you want to avoid querying the database.
However, if the instance is then later used (accidentally or occasionally,
that would defeat the point of the optimisation), the value of
`MyModel.relatedfield` can be incorrect. I think inefficient would be a
better default than incorrect, because the mistake is subtle.
I imagine the `ForwardManyToOneDescriptor` could check the primary key of
the cache value being returned against the primary key on the model
instance and if there is a mismatch, then the cache value should be
deleted and a new query should be made.
{{{
>>> instance = MyModel(relatedfield_id=1)
>>> print(instance.relatedfield.pk)
1
>>> instance.relatedfield_id = 2
>>> print(instance.relatedfield.pk)
1
>>> instance.save()
>>> print(instance.relatedfield.pk)
1
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/27710>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Will Hardy | Owner: nobody
Cleanup/optimization |
Component: Database layer | Version: 1.10
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* component: Uncategorized => Database layer (models, ORM)
* type: Uncategorized => Cleanup/optimization
* stage: Unreviewed => Accepted
Comment:
I thought there might be another ticket where this was proposed and
possibly rejected as "too magical", but I'm not going to do a search now.
The idea seems reasonable at first glance.
--
Ticket URL: <https://code.djangoproject.com/ticket/27710#comment:1>
Django
Reporter: Will Hardy | Owner: Paulo
Type: | Status: assigned
Cleanup/optimization |
Component: Database layer | Version: 1.10
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Paulo):
* owner: nobody => Paulo
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/27710#comment:2>
Django
Reporter: Will Hardy | Owner: Paulo
Type: | Status: assigned
Cleanup/optimization |
Component: Database layer | Version: 1.10
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Paulo):
* has_patch: 0 => 1
Comment:
PR: https://github.com/django/django/pull/9122
--
Ticket URL: <https://code.djangoproject.com/ticket/27710#comment:3>
Django
Reporter: Will Hardy | Owner: Paulo
Cleanup/optimization |
Component: Database layer | Version: 1.10
(models, ORM) |
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham <timograham@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"ee49306176a2d2f1751cb890bd607d42c7c09196" ee493061]:
{{{
#!CommitTicketReference repository=""
revision="ee49306176a2d2f1751cb890bd607d42c7c09196"
Fixed #27710 -- Made Model.save() invalidate cached, stale relations after
a primary key assignment.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/27710#comment:4>