On Wed, Mar 7, 2012 at 9:13 PM, akaariai <akaar...@gmail.com> wrote: > I believe the reason is efficiency. If there were an on_delete > argument for GFKs every object deletion of any class would need to do > a query to check if there happens to be any GFK related objects. In > addition, Django can't guarantee foreign key consistency. In case of > concurrent transactions it is possible an insert could be made which > is not visible to the deletion code. >
Hi Anssi, thanks for your answer! :) Maybe I've missunderstood your email, but I don't see why a customization of the on_delete behaviour could lead to performance or concistency issues. Actually the default behaviour of GFK (with a declared GenericRelation) is performing a delete on cascade, so Django is currently performing this hard work looking for related objects to delete. My problem is just this, avoiding the cascade deletion. More precisely, I want to have a GenericRelation declared in order to get their extra API features, but at the same time i want to keep my related objects when a related delete is performed, so it would be nice if I can define on_delete=DO_NOTHING. It doesn't sound too much complicated to implement on django trunk, so I want to know if I'm missing something. Please let me know if I didn't understand correctly your comment. -- Marc -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.