Hi Christophe, On 09/26/2013 04:28 PM, Christophe Pettus wrote: > On Sep 26, 2013, at 2:32 PM, Carl Meyer <[email protected]> wrote: >> We already provide the on_delete=DO_NOTHING option for people who >> want to push cascade handling to the database. > > It's better than the previous situation, but the steps required to > make this work make it a non-starter for any but the most trivial of > projects. I do, however, accept that we're painted into a corner > with the current API. > > I would strongly advocate for a way of doing this push, however: It's > much more efficient for cascading without exotic additions such as > signals. The current way one has to do it has several problems: > > 1. You are, in essence, lying in your model about what is going to > happen, by saying on_delete=DO_NOTHING and then doing something in > the database itself. > > 2. Since Django creates the foreign key constraints and gives them > unpredictable names, you have to write a very tedious, error-prone > South migration to install the appropriate foreign key constraints, > something that Django could very easily do. > > Perhaps a CASCADE_DB and SET_NULL_DB options on on_delete?
Agreed on all counts. Presuming that the documentation is clear about the tradeoffs, I think these could be very nice additions to save some of that tedium and make in-db cascade easier to achieve. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
