#9527 closed (fixed)
Model.save_base() depends on Model._default_manager
Reported by: | Owned by: | Malcolm Tredinnick | |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.0 |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
In qs-rf, Model.save_base
was refactored to check whether to perform an SQL UPDATE versus INSERT using the Model's default manager rather than raw SQL. This means that the ORM now breaks if the default manager does filtering. Any model instance that is not returned by default cannot be successfully updated. The ORM does not find the copy already saved, and tries to insert instead, causing an IntegrityError
.
My manager looks like this:
class PropertyManager(models.Manager): def get_query_set(self): """By default, exclude properties not even committed""" return super(PropertyManager, self).get_query_set().exclude(status='--') def uncommitted(self): """Retrieve those properties that are not queried by default""" return super(PropertyManager, self).get_query_set().filter(status='--')
The intention was for the default manager to only return committed properties. Nowhere on the site should uncommitted properties appear: these uncommitted properties exist only while being constructed using a wizard (but need to be in the database, not just the session, so models.ImageField
works).
According to the documentation for default managers (http://docs.djangoproject.com/en/dev/topics/db/managers/), you must "be careful in your choice of default manager", but this does not state that a default manager must return all rows or risk breakage.
The expectation is that saving should work regardless of the default manager.
Change History (5)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:3 by , 16 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
(In [10056]) Use plain model.Manager, or suitable proxy, for model saving.
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.
Refs #2698 (which is not fixed by this change, but it's the first part of a
larger change to fix that bug.)
comment:5 by , 16 years ago
(In [10059]) [1.0.X] Use plain model.Manager, or suitable proxy, for model saving.
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.
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.
A workaround is to monkey-patch
_default_manager
for the duration of the.save()
call