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

Comment (by akaariai):

 Just a mention about the future changes which might make sense:
   - Move the path generation code (the ugly stuff in names_to_path()) to
 fields. There is little reason the ORM code needs to know the internal
 implementation of the fields (how the field.rel.to... stuff). If this is
 done in fields instead this will allow for cleaner code in sql/query.py
 and also custom field subclasses can easily customize the behaviour of the
 join setup.
   - Move the names_to_path() call to beginning of add_filter(). This
 allows fixing some bugs related to F() expression handling and also allows
 the removal of MultiJoin exception.
   - Generate the join condition fully by the field. This would make the
 ORM agnostic about multiple columns in the join, and it would be possible
 to generate completely custom join clause for cases like what is discussed
 in #373 comment 111.
   - Some cleanup to the model._meta get_* methods. It could be possible to
 reduce the amount of different field types and the different get_foo
 methods related to these - if the field would tell what type of relation
 it is, then we need to just get a handle to the field and we are done. How
 much we want to actually change the ._meta is a good question - if
 anything is semi-public API then it is model._meta.

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


Reply via email to