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
A custom manager on a related object that filtered away objects would prevent
those objects being deleted via the relation. This is now fixed.
Backport of r10104 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@10106 bcc190cf-cafb-0310-a4f2-bffc1f526a37
We can't use the default manager in Model.save_base(), since we need to
retrieve existing objects which might be filtered out by that manager. We now
always use a plain Manager instance at that point (or something that can
replace it, such as a GeoManager), making all existing rows in the
database visible to the saving code.
The logic for detecting a "suitable replacement" plain base is the same as for
related fields: if the use_for_related_fields is set on the manager subclass,
we can use it. The general requirement here is that we want a base class that
returns the appropriate QuerySet subclass, but does not restrict the rows
returned.
Fixed#8990, #9527.
Refs #2698 (which is not fixed by this change, but it's the first part of a
larger change to fix that bug.)
Backport of r10056 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@10059 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Adding a get_db_prep_save() call to the UpdateQuery code path meant it
was being called twice if you updated an existing model attribute. This
change removes that double call and also makes TimeField.to_python() a
little more robust for the benefit of the Oracle backend (just in case).
Backport of r10013 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@10014 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Previously, you could explicitly assign None to a non-null ForeignKey
(or other) field when creating the model (Child(parent=None), etc). We
now throw an exception when you do that, which matches the behaviour
when you assign None to the attribute after creation.
Thanks to ales.zoulek@gmail.com and ondrej.kohout@gmail.com for some
analysis of this problem.
Backport of r9983 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@9984 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This fixes a broad class of bugs involving filters that look for missing
related models and fields. Most of them don't seem to have been reported
(the added tests cover the root cause). The exception is that this has
also fixed#9968.
Backport of r9979 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@9980 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Manually specifying both a OneToOneField(parent_link=True) and separate a
primary key field was causing invalid SQL to be generated. Thanks to Ramiro
Morales for some analysis on this one.
Backport of r9971 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@9973 bcc190cf-cafb-0310-a4f2-bffc1f526a37
If an update only affected an ancestor model (not the child), we were
returning 0 for the number of rows updated. This could have been
misleading if the value is used to detect an update occuring. So we now
return the rowcount from the first non-trivial query that is executed
(if any). Still a slight compromise, but better than what we had.
Backport of r9966 from trunk (turns out this *is* a bugfix, since the returned
rowcount is used in Model.save(force_update=True)).
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@9969 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This includes a fairly large refactor of the update() query path (and
the initial portions of constructing the SQL for any query). The
previous code appears to have been only working more or less by accident
and was very fragile.
Backport of r9967 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@9968 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
Also enhanced the new test to hopefully exercise all paths through the get_deleted_objects function, and fixed the errors pointed out by the beefed-up test.
r9656 and r9657 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@9658 bcc190cf-cafb-0310-a4f2-bffc1f526a37
that was passed in for the connector. This was contrary to what the
documentation for autoescaping said and to what every other filter does
with literal strings as arguments.
This is backwards incompatible for the situation of the literal string
containing one of the five special HTML characters: if you were writing
{{ foo|join:"&" }}, you now have to write {{ foo| join:"&" }}.
Previous behaviour was, as noted, a bug and contrary to what was
documented and expected.
Backport of r9442 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@9443 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This case pops up with generic foreign key inlines after [9297]. Added tests
to handle future regressions with generic foreign key inlines in the admin.
Thanks markus and danielr for patches.
Backport of [9412] from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@9413 bcc190cf-cafb-0310-a4f2-bffc1f526a37
