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
2698	Custom default managers interfere with delete operations	anonymous	Malcolm Tredinnick	"In our model, we have a Story class, with a boolean 'deleted' 
attribute.  We defined a custom default manager to return all of the 
stories that are not deleted, so that most of the code on the site will 
not have to deal with filtering out the deleted stories (there's another 
custom manager called with_deleted for those code paths that need to see 
the deleted stories as well).

The problem comes up when deleting a user.  The deletion code iterates 
the user's stories to delete them, but uses the default manager, so 
stories with deleted=1 are not found.  So (ironically) any stories 
marked with the 'deleted' field are not actually deleted when the user 
is removed.  This prevents the user from being deleted, because the 
story table still has a foreign key reference to the user table, and 
MySQL prevents the user record from being deleted.

The docs for custom managers say: ""it's generally a good idea for the 
first Manager to be relatively unfiltered"".  But it seems that any 
filtering in the default manager will interfere with cascading deletes. 

If the default manager does any filtering at all, then deleting an object may fail because its related objects will not all be deleted, and the database's referential integrity will prevent the deletion.  When looking for related obejcts to delete, you have to always get all of them.  No filtering allowed."	defect	closed	Database layer (models, ORM)	dev	normal	fixed		ned@…	Accepted	0	0	0	0	0	0