#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 | -------------------------------------+-------------------------------------
Comment (by sebastian): @akaariai: Your patch looks good, and I think that unifying the promotion of joins to a single method `promote_joins` makes sense. It might also fix some issues with nested foreign keys that my patch wouldn't catch. One remark, however: on first sight, `promote_joins` doesn't seem to work recursively, i.e. the order in which we pass joins to this method matters (if one join references the other, passing them in in the opposite order might not lead to the desired avalanche of promotion). Is this a problem? Should we re-run the promotion until all join types stabilize, in order to catch such inter-join dependencies? Also, why do you exclude `auth_permission` and `django_content_type` from promotion? That `if`-statement should at least have a comment explaining the reason for this. -- Ticket URL: <https://code.djangoproject.com/ticket/16715#comment:12> 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 django-updates@googlegroups.com. To unsubscribe from this group, send email to django-updates+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-updates?hl=en.