Python beta releases. Failures there mean that incorrect code won't raise an
error, but it's otherwise harmless (correct code still runs correctly).
Fixed#7786.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8570 bcc190cf-cafb-0310-a4f2-bffc1f526a37
aren't always equivalent. This is documented, stable behaviour, so we should
ensure it doesn't change accidentally.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8312 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Based on a patch from Justin Bronn.
The test in this patch most likely breaks on Oracle. That's another issue.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8053 bcc190cf-cafb-0310-a4f2-bffc1f526a37
The problem being "hidden" here is not serious. It won't affect correct code
and only gives a different failure mode for incorrect code. The moral is: don't
write incorrect code.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7939 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Patch from mturtle@gmail.com. The remaining uses of "%s__pk" in
fields/related.py all look safe, since they are for many-to-many fields, which
doesn't take "to_field" as a parameter.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7785 bcc190cf-cafb-0310-a4f2-bffc1f526a37
We no longer store any reference to Django field instances or models in the
Where node. This should improve cloning speed, fix some pickling difficulties,
reduce memory usage and remove some infinite loop possibilities in odd cases.
Slightly backwards incompatible if you're writing custom filters. See the
BackwardsIncompatibleChanges wiki page for details.
Fixed#7128, #7204, #7506.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7773 bcc190cf-cafb-0310-a4f2-bffc1f526a37
These types of relations don't have reverse accessor names, so that name can be
used by a normal field on the model. Fixed#7107.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7764 bcc190cf-cafb-0310-a4f2-bffc1f526a37
so that the ordering doesn't accidentally restrict the result set.
(Ironically, one existing test actually showed this problem, but I was too
dumb to notice the result was incorrect.)
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7761 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Field.db_type().
This fixes a problem with using reserved words for field names in Oracle. Only
affects Oracle at the moment, but the same changes could easily be used by
other backends if they are required (requires changing creation.py, only).
This commit also reverts [7501] so that if the fix doesn't work, it will show
up in the tests (and if it does work, the tests will prevent us from breaking
it again).
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7743 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Avoids joining with the wrong tables when connecting select_related() tables to
the main query. This also leads to slightly more efficient (meaning less tables
are joined) SQL queries in some other cases, too. Some unnecessary tables are
now trimmed that were not previously.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7741 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Previously, if we were querying across a nullable join and then a non-nullable
one, the second join would not be a LEFT OUTER join, which would exclude
certain valid results from the result set.
This is the same problem as [7597] but for values() field specifications, so
this covers the second case where Django adds extra stuff to the select-clause.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7740 bcc190cf-cafb-0310-a4f2-bffc1f526a37
marked as erroneous. It's just more dangerous and risky, not forbidden. This
commit restores backwards compatibility there.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7490 bcc190cf-cafb-0310-a4f2-bffc1f526a37
