> It's not just the referential integrety - even though that's complicated enough, with ISPs not allways installing newest versions of databases - but the .delete() overloading, too. If your class overloads .delete() to do specific stuff, that code will not be called when you do bulk deletes.
Doesn't the delete function also checks permissions on all the referenced rows? I don't think you can implement this in SQL. Frankly, the bulk delete seems to have some problems with usability, too. I've deleted objects that have somewhere around 20 or 30 references and the screen it filled. If I was trying to delete in bulk, it would be unusable. I think it would be better to treat a "bulk" operation differently from the regular one, somehow. For example, I would suggest an extra "can_bulk_delete_model" permission, and instead of showing all the related objects in the confirm delete screen, just show the parent objects themselves. This would avoid confusion with "custom" delete functions because those functions would never be called. -rob
