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
This is for Manager subclasses that are default managers, but only
sometimes. The general rule is: "don't use it." If you really need it,
read the instructions.
Backport of r10057 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@10060 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
This only shows up in for reverse() (not forwards resolving), since that
path uses a globally shared resolver object. Based on a patch from
Travis Terry.
Backport of r10037 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@10039 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
This removes a long-standing FIXME in the update() handling and allows for
greater flexibility in the values passed in. In particular, it brings updates
into line with saves for django.contrib.gis fields, so fixed#10411.
Thanks to Justin Bronn and Russell Keith-Magee for help with this patch.
Backport of r10003 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@10004 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
This was always not working reliably (model initialization and serialization
were two of the problems). Now, it's an explicit error. Also, documented.
Fixed#10252.
Backport of r9974 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@9975 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
Malcolm Tredinnick
Ian Kelly
Russell Keith-Magee
Jacob Kaplan-Moss
Jannis Leidel
Karen Tracey
Jarek Zgoda