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
Now you can import the file storage stuff and still call settings.configure()
afterwards. There is still one import-time usage of settings in
django.contrib.comments, but that's unavoidable.
Backport of r9945 and r9946 from trunk (this is needed in order to fix#8193 in
a clean fashion, which is why it's being backported).
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@9947 bcc190cf-cafb-0310-a4f2-bffc1f526a37
The cache tests have been failing for a long time with the db backend. This
change makes them pass again, so no test changes required here.
Backport of r9942 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@9943 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Allows us to reuse the same code in multiple places, avoiding new and
interesting bugs (the testing framework had a DIY version that was slightly
wrong, for example). Fixed#9833.
Backport of r9936 from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@9937 bcc190cf-cafb-0310-a4f2-bffc1f526a37
