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 django-develop...@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.
