#17485: Queries with both deferred fields and select_related defer field.name
instead of field.attname
-------------------------------------+-------------------------------------
Reporter: koniiiik | Owner: koniiiik
Type: Bug | Status: new
Component: Database layer | Version: SVN
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: defer | Needs documentation: 0
select_related | Patch needs improvement: 0
Has patch: 1 | UI/UX: 0
Needs tests: 0 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by koniiiik):
* owner: nobody => koniiiik
Comment:
Replying to [comment:1 aaugustin]:
> It seems to me that `select_related` is the opposite of `defer`. Is
there a use case for using both on the same field? Maybe it's
`.defer('foo').select_related('foo__bar__baz')`, in order to fetch `foo`,
`bar` and `baz` in one query on the first access to `foo`? (Does that
actually work?)
Nope, that does not work nor do I think there's an easy way to make it, at
least with the current implementation of deferred fields. The whole
example I've given is based on the two failing test cases, I can't imagine
any sane use case at the moment.
I think the test was meant more like something to make sure the ORM
doesn't omit a field on which it makes a join, i. e. issuing a
`select_related` on a deferred field will make the field immediate.
I've come up with a way to fix this, I'll try to implement it later today.
--
Ticket URL: <https://code.djangoproject.com/ticket/17485#comment:2>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
