id,summary,reporter,owner,description,type,status,component,version,severity,resolution,keywords,cc,stage,has_patch,needs_docs,needs_tests,needs_better_patch,easy,ui_ux 9527,Model.save_base() depends on Model._default_manager,Daniel Pope ,Malcolm Tredinnick,"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.",,closed,"Database layer (models, ORM)",1.0,,fixed,,,Accepted,0,0,0,0,0,0