django.git/django/db/models/sql/query.py, branch 1.5c1

[1.5.x] Fixed #14694 -- Made ``defer()`` work with reverse relations

2012-11-28T16:25:34Z

Reverse o2o fields are now usable with defer. Backpatch of [6ebf115206289bce8f3d86318871faac13d6e835]

[1.5.x] Fixed #18375 -- Removed dict-ordering dependency for F-expressions

2012-11-23T18:07:50Z

F() expressions reuse joins like any lookup in a .filter() call - reuse multijoins generated in the same .filter() call else generate new joins. Also, lookups can now reuse joins generated by F(). This change is backwards incompatible, but it is required to prevent dict randomization from generating different queries depending on .filter() kwarg ordering. The new way is also more consistent in how joins are reused. Backpatch of 90b86291d022a09031d1df397d7aaebc30e435f7

Removed use of SortedDict for query.alias_refcount

2012-11-13T21:01:34Z

This will have a smallish impact on performance. Refs #19276.

Fixed regression caused by #19102

2012-10-25T16:13:10Z

Fixed #19102 -- Fixed fast-path delete for modified SELECT clause cases

2012-10-25T14:16:44Z

There was a bug introduced in #18676 which caused fast-path deletes implemented as "DELETE WHERE pk IN " to fail if the SELECT clause contained additional stuff (for example extra() and annotate()). Thanks to Trac alias pressureman for spotting this regression.

Fixed #19087 -- Ensured query's base table is never LOUTER joined

2012-10-08T15:40:09Z

This fixes a regression created by join promotion logic refactoring: 01b9c3d5193fe61b82ae8b26242a13fdec22f211 Thanks to Ivan Virabyan for the report.

Internal refactoring; moving LOOKUP_SEP up one level.

2012-09-08T23:51:36Z

In an ideal world, nothing except django.db.models.query should have to import stuff from django.models.sql.*. A few things were needing to get hold of sql.constants.LOOKUP_SEP, so this commit moves it up to django.db.models.constants.LOOKUP_SEP. There are still a couple of places (admin) poking into sql.* to get QUERY_TERMS, which is unfortunate, but a slightly different issue and harder to adjust.

Cleaned up some small bits of the ORM, including removing an import *.

2012-09-07T14:58:17Z

Fixed #16715 -- Fixed join promotion logic for nested nullable FKs

2012-08-25T11:14:45Z

The joins for nested nullable foreign keys were often created as INNER when they should have been OUTER joins. The reason was that only the first join in the chain was promoted correctly. There were also issues with select_related etc. The basic structure for this problem was: A -[nullable]-> B -[nonnull]-> C And the basic problem was that the A->B join was correctly LOUTER, the B->C join not. The major change taken in this patch is that now if we promote a join A->B, we will automatically promote joins B->X for all X in the query. Also, we now make sure there aren't ever join chains like: a LOUTER b INNER c If the a -> b needs to be LOUTER, then the INNER at the end of the chain will cancel the LOUTER join and we have a broken query. Sebastian reported this problem and did also major portions of the patch.

Fixed #17886 -- Fixed join promotion in ORed nullable queries

2012-08-21T18:23:57Z

The ORM generated a query with INNER JOIN instead of LEFT OUTER JOIN in a somewhat complicated case. The main issue was that there was a chain of nullable FK -> non-nullble FK, and the join promotion logic didn't see the need to promote the non-nullable FK even if the previous nullable FK was already promoted to LOUTER JOIN. This resulted in a query like a LOUTER b INNER c, which incorrectly prunes results.