Using select_related(...) across a nullable relation to a multi-table
model inheritance situation no longer excludes results. Thanks to AdamG
for a test demonstrating part of the problem.
Backport of r10136 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@10138 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Some results were inadvertently being excluded if we were ordering across a
nullable relation which itself ordering by a non-nullable relation.
Backport of r9916 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@9917 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Backport of [9254] from trunk (I neglected to mention in the ticket this affected 1.0.X branch).
Also updated svnmerge metadata; all eligible fixes have been backported and all others blocked.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@9275 bcc190cf-cafb-0310-a4f2-bffc1f526a37
display more than 20 objects.
This means that accidentally executing HugeStoryArchive.objects.all() at the
interactive prompt (or in the debug template) won't try to load all 4,233,010
stories into memory and print them out. That would previously cause resource
starvation and other "interesting" crashes.
If you really, really want the previous behaviour (e.g. in a doctest that
prints more than 20 items), display "list(qs)" instead of just "qs".
Backport of r9202 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@9205 bcc190cf-cafb-0310-a4f2-bffc1f526a37
"having" attributes, only the former was included in the resulting SQL, meaning
subclasses had to completely duplicate Query.as_sql() if they were using any
kind of grouping filtering on the results.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9007 bcc190cf-cafb-0310-a4f2-bffc1f526a37
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
