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