#11319: ForeignKey filters use the wrong field to prepare values for database
---------------------------------------------------+------------------------
Reporter: russellm | Owner: carljm
Status: new | Milestone: 1.3
Component: Database layer (models, ORM) | Version: 1.0
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------
Changes (by carljm):
* needs_docs: 1 => 0
Comment:
Replying to [comment:17 russellm]:
> My only suggested addition to the patch would be some documentation to
describe the edge case -- presumably in the documentation for to_field.
I spent a little while working on some draft documentation, and my
conclusion is that I think no addition to the docs is actually warranted
here. The behavior we are fixing it to is quite intuitive (which is why we
can consider it a bug that it ever was otherwise), and the explanation of
why it's even worth explaining at all is comparatively difficult (requires
explanation of what is meant by "forward" or "reverse" lookups across a
self-referential foreign key, which is hard to explain clearly without a
full example). In the end, all I can come up with is either a short one-
sentence note that feels opaque and probably useless, or a longer
explanation, using the Category example, that is IMO too many paragraphs
wasted on such an obscure case, given that I don't think someone running
across this behavior is likely to find it particularly surprising or
noteworthy.
Anyway, I pushed the long-version draft docs to
https://github.com/carljm/django/commit/f949b52fea10f06423648c476878a2218587db66
- the short and opaque version would consist of only the first sentence of
that (and probably eliminating the versionadded marker? We don't usually
do that for bugfixes, but it seems like it's needed if we're giving a full
code example that we know doesn't work on older versions...). As I said, I
think the best option here is no docs change at all.
The one other thing that's making me uncomfortable about committing this
as a fix here, is that right now this bug is the only open reference to
some unspecified "deep-seated issue" with get_db_prep_lookup and related
fields that Malcolm was apparently working on at some point (discussed in
#10243 and #10785). Currently my best theory is that that issue probably
has to do with what I discuss above: how get_db_prep_lookup on a related
field is used for both forwards and reverse lookups without knowing which
it is. If that's the issue, I think I'm OK saying that at this point it
doesn't appear to be something that needs to be fixed for any practical
use case. But I'd be glad for any light Russell or Malcolm could shed on
what this "deep-seated issue" is/was, and whether we should be keeping a
bug open for it.
--
Ticket URL: <http://code.djangoproject.com/ticket/11319#comment:18>
Django <http://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.