#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.

Reply via email to