Saving an object with a custom manager results in IntegrityError

[loekje]

I have defined customer manager that filters out certain object (e.g. those objects marked as inactive).
The customer manager is the first manager defined in the model, consequently it is used as the default manager for this model.
Additionally, I have defined another manager for the model that does no filtering (i.e. the standard manager).

When properties of an inactive object are updated and the inactive object is saved, an IntegrityError is raised. This is because the default manager cannot find the object and attempts to insert the object again instead of updating it.

class MyModelManager(models.Manager):
   def get_query_set(self):
      return super(MyModelManager, self).get_query_set().filter(is_active=True)

class MyModel: models.Model
   name=CharField
   ... some additional properties ...
   is_active=BooleanField

   objects=MyModelManager()
   objects_all=models.Manager()

m=MyModel()
m.name='John'
m.is_active=False
m.save()

m.name='John Doe'
m.save()
--> IntegrityError!!!

I would like that the default manager can be set such that inactive objects are not shown (i.e. also not when using mymodel_set on related objects) such that by default the inactive objects are not taken into account. However, to avoid the IntegrityError when saving an object I would like to be capable of overruling a manager that has to be used by save (and most likely also by delete), in the model and/or as in argument in the save call.

[Alex Gaynor]

I've reformatted the description of this ticket, in the future you can use the "Preview" button to ensure that your message is formatted the way you intended.

[Gabriel Hurley]

I can't reproduce this failure on trunk or 1.2 with the code provided.

1. Your example code works just fine when run on a clean project.
2. Reading the source for Model.save, which in turn calls Model.save_base, the default manager is *not* used. Saving is done with _base_manager which should be an instance of models.Manager in all cases I'm aware of.

If you can provide a failing test case (bonus points if it's in the form of a unit test for the Django test suite), please reopen the ticket.

However, if you're really reporting this from a version 1.0 installation of Django, it's almost certainly been fixed subsequently, and 1.0 is no longer even an officially "supported" version according to the release process docs.

[Matthias Kestenholz]

I think this has been fixed in [10056]