#10790: Too many joins in a comparison for NULL.
-------------------------------------+-------------------------------------
     Reporter:  mtredinnick          |                    Owner:
         Type:  Bug                  |  mtredinnick
    Component:  Database layer       |                   Status:  new
  (models, ORM)                      |                  Version:  master
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:  Accepted
    Has patch:  1                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  1
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by akaariai):

 milosu: I added comment to #17886, I think you are on right track but the
 patch needs some polish.

 For the idea of trimming joins before even adding them: it doesn't work.
 The reason is a query like this:
 {{{
 qs.filter(relatedf__isnull=True)
 }}}
 This will first create a LOUTER join to the relatedf. Then trim it away
 (that is, make its refcount 0). Now, later on if we need another join to
 relatedf we know to make it LOUTER, this could happen in queryset
 combining `(qs|qs.filter(relatedf__somecol=someval))` for example.

 So, we need to have the LOUTER trimmed join information available
 somewhere. Using my patch from above we could just move the join trimming
 to just after creating the joins, and pass the information about the need
 of LOUTER join to setup_joins. Now, we can immediately trim the non-needed
 joins, and in addition we have the information about LOUTER available. I
 tested this quickly and it works.

 The question now is if we need trim_joins() at all. If we do, then it
 might be better to just pass the information about the direction to
 trim_joins and modify it to do the join trimming properly. If we don't
 need trim_joins anymore, then doing the trimming in setup_joins seems like
 the correct approach.

 In any case the information about the need of having information about
 trimmed joins available needs to be documented in code.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/10790#comment:37>
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 https://groups.google.com/groups/opt_out.


Reply via email to