#16715: Wrong JOIN with nested null-able foreign keys
-------------------------------------+-------------------------------------
     Reporter:  sebastian            |                    Owner:  nobody
         Type:  Bug                  |                   Status:  new
    Component:  Database layer       |                  Version:  SVN
  (models, ORM)                      |               Resolution:
     Severity:  Normal               |             Triage Stage:  Accepted
     Keywords:  join, values,        |      Needs documentation:  0
  nested, foreign key, null-able     |  Patch needs improvement:  0
    Has patch:  1                    |                    UI/UX:  0
  Needs tests:  0                    |
Easy pickings:  0                    |
-------------------------------------+-------------------------------------
Changes (by sebastian):

 * needs_better_patch:  1 => 0


Comment:

 No problem. I took your patch and adapted it to the current SVN version of
 Django ("16715_alternate-redux-r16928.diff"). Some changes were necessary
 as there seem to be more instances of `promote_alias[_chain]` in the
 current version.

 I also added the ability to examine all children of the joins passed to
 the new method `promote_joins`. This should make sure that all known
 references to a join get updated as well. In fact, this change might
 enable us to remove all calls to `promote_alias[_chain]`/`promote_joins`
 until just before the final construction of the query. Until now, it seems
 that we had to call `promote_alias[_chain]` repeatedly whenever we changed
 certain aspects of the query, to ensure the correct join type. However,
 this might not be necessary anymore as the new method `promote_joins` does
 the promotion recursively (when A->B gets promoted, so do all B->X).

 What do you think? Moving the promotion of joins right to the end of the
 query construction might simplify the code, since we only had to collect
 the requirements of each join (ie. referenced alias, fields, and if the
 join itself is nullable) and would add the join type only just before
 putting everything together (JOIN_TYPE would remain unset until this very
 last step). At least, this seems like the logical thing to do, anyway, but
 I don't know if JOIN_TYPE is used for other things during query
 construction (I guess it is).

 BTW, the new patch too doesn't introduces any new failed tests.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/16715#comment:15>
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.

Reply via email to