Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#14295 closed (worksforme)

Saving an object with a custom manager results in IntegrityError

Reported by: loekje Owned by: nobody
Component: Uncategorized Version: 1.0
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description (last modified by Alex)

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
   ... some additional properties ...


m.is_active=False'John Doe'
--> 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.

Change History (3)

comment:1 Changed 5 years ago by Alex

  • Description modified (diff)
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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.

comment:2 Changed 5 years ago by gabrielhurley

  • Resolution set to worksforme
  • Status changed from new to closed

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, 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.

comment:3 Changed 5 years ago by mk

I think this has been fixed in [10056]

Note: See TracTickets for help on using tickets.
Back to Top