The problem description in #18239 asserted that
http://bugs.python.org/issue670664 was fixed in Python 2.6.8, but based on
http://bugs.python.org/issue670664#msg146770 it appears that's not correct; the
fix was only applied in 2.7, 3.2, and Python trunk. Therefore we must use our
patched HTMLParser subclass in all Python 2.6 versions.
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.
Some backends issue a warning here, others not. This is not the primary
goal of the test, so the assertion about the warning has been removed.
Thanks Carl Meyer for noticing the issue and suggesting the fix.
During the new-admin changes, catching of AttributeError was added to
the admin. This patch removes that as it's no longer possible to add a
value to a ModelAdmin that is not available. Adding an attribute that
can not be called causes an ImproperlyConfigured exception to be raised.
Previous this used Python's builtin hash() function, which has never been guarnteed to be stable across implementations (CPython/Jython/etc.) or 32/64 bitness. However, this in practice it was stable. However, with the impending release of Python 3.3 hash randomizations is enabled by default, which would mean the index name changed between program invocations.
Unlike other model fields, the newly introduced (1.4)
GenericIPAddressField did not accept verbose_name and name as the
first positional arguments. This commit fixes it.
Thanks Dan McGee for the report and the patch.
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.