It's quite a common practice to customize a model's delete method. This normally leads to the recommended practice of "just loop through instances and delete each in lieu of using QuerySet.delete". That works well, within limited context. However, when you've got a model that's high up in the food chain (e.g. Tenant) with more than a few foreign keys pointing to it, having to override Tenant.delete to account for each of it's dependents that have custom delete methods leads to tight coupling. Furthermore, pointing foreign keys to out-of- band models like User leads to more bad practices, like monkey patching.
My proposal is to add a new on_delete=models.SET-ish feature (or a new kwarg altogether) which would, when specified, cause the parent object's delete to loop through an iterator of the related instances and call the delete method on each for me. I wouldn't think that a transaction would need to be applied in-place, as the docs could merely mention the warning about multiple queries, inferring the need for a transaction (leaving flexibility). table = models.ForeignKey(Restaurant, on_delete=models.CALL_DELETE) or table = models.ForeignKey(Restaurant, bulk_delete=False) I prefer the former to the latter. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
