On Fri, Nov 5, 2010 at 1:27 AM, Carl Meyer <[email protected]> wrote: > Hi all, > > The patch for #7539 [1] (support for on_delete behaviors other than > cascading deletes) has reached a state where I consider it a candidate > for committing; I invite review and comments. The current patch is > available as a github branch; the compare view [2] presents it nicely > as a diff with trunk. The patch is mostly the (excellent) work of > Johannes Dollinger, with some additional work by myself and Alex > Gaynor. > > Quick feature summary: the patch adds an on_delete argument to > ForeignKey (and, by extension, OneToOneField). This argument can be > set to any of the following: > > - CASCADE -- the current behavior > - PROTECT -- raise IntegrityError on attempts to delete the referenced > object > - SET_NULL -- (if the FK is nullable) > - SET_DEFAULT -- (if the FK has a default) > - SET(value) -- set to some arbitrary value; also accepts a callable > - DO_NOTHING -- let the database handle it (up to you to create/alter > your tables with appropriate ON DELETE constraints) > > The patch does not add on_delete support to GenericForeignKey; it > retains the current (and documented) behavior, where models with a > GenericRelation back to the GFK model will cascade deletes. I spent > several evenings working on extending on_delete support to GFK (that > work is visible in the t7539-gfk branch on my github), and my > conclusion from the attempt is that GFKs need a rethinking before we > special-case any more support for them into other parts of the ORM. > GFKs currently don't fit into any abstraction or extension point that > the ORM understands (i.e. they're a hack), and adding support for them > here requires piling hacks on top of hacks. To deal with the root > problem, the ORM needs to gain a sensible public abstraction for > virtual or composite fields, which GFKs can become an instance of. If > that's done right, support for them in this feature (and all other ORM > features) will fall out naturally. But that's a different task, and I > don't think we should hold up this patch for it. As it stands, it's > easy enough as a workaround to get "do nothing" behavior for GFKs > simply by not using GenericRelation, and/or implement whatever > behavior you like via deletion signals. > > In addition to adding the on_delete feature, the patch simplifies and > clarifies the deletion code (~50 line net reduction in non-test code), > adds test coverage (+200 lines test code), and is much faster than the > previous code for large bulk deletes (fixes #13067 [3]). It also adds > documentation in the QuerySet API reference for QuerySet.delete (fixes > #14599 [4]). > > I've run the full test suite under Python 2.6 on SQLite and Postgres > (8.4), and deletion-related tests (delete, on_delete, delete_regress, > admin_views.AdminViewDeletedObjectsTest) on MySQL/ISAM. I've also run > the tests against Python 2.4 and 2.5 (SQLite). Test runs against other > database backends would be very helpful. > > I'd like to commit this early next week, depending on feedback. > > Many thanks to Johannes Dollinger for the patch, and to Alex Gaynor > for review and updates. > > Carl > > [1] http://code.djangoproject.com/ticket/7539 > [2] https://github.com/carljm/django/compare/master...t7539 > [3] http://code.djangoproject.com/ticket/13067 > [4] http://code.djangoproject.com/ticket/14599 > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > >
It goes without saying, but I'm +1 on the patch, both API and implementation. Thanks for championing this one Carl, and thanks to Johannes for writing the patch and keeping it warm all through the 1.2 cycle. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
