On Mar 7, 11:40 pm, Marc Aymerich <glicer...@gmail.com> wrote: > 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.
Seems like I was mistaken. I thought there was no on_delete action at all. If there already is one I don't see any other reason for not allowing customization of the action than that nobody has implemented that yet. I don't use GFKs myself, so that was the reason for the confusion. Sorry for misinformation... - Anssi -- 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.
