#7539: Add ON DELETE and ON UPDATE support to Django
---------------------------------------------------+------------------------
          Reporter:  glassfordm                    |         Owner:         
            Status:  new                           |     Milestone:         
         Component:  Database layer (models, ORM)  |       Version:  SVN    
        Resolution:                                |      Keywords:  feature
             Stage:  Design decision needed        |     Has_patch:  1      
        Needs_docs:  1                             |   Needs_tests:  0      
Needs_better_patch:  0                             |  
---------------------------------------------------+------------------------
Comment (by anonymous):

 @glassfordm: Is it possible that you forgot to `svn add` your tests before
 making the diff? I can't find any `on_delete` related tests, except a
 handful of low level tests for `CollectedFields`.

 The patch I just attached is based on `on_delete_on_update-r11620.diff`. I
 made the following changes:

  * Removed checks for `default` and `null` in `_handle_sub_obj()` (as
 these are static properties of fields and already checked in
 `contribute_to_class()`). These checks should perhaps be moved to
 `django.core.management.validation`.

  * Moved instance-update and sql-update code inside `CollectedFields` so
 the actual data structure doesn't have to be known to code outside. Is
 there a reason field updates are not simply collected in
 `CollectedObjects`, too?

  * Changed how update queries are performed: instead of one per instance,
 it now uses one (batch) per field. Except for corner cases (more than
 GET_ITERATOR_CHUNK_SIZE foreign keys on a single model affected), this
 results in fewer queries.

  * Added a pony of mine: `on_delete=DO_NOTHING`, which would help with
 #10829.

 I didn't write any tests (bad), but all existing tests pass. Which
 hopefully means that at least I haven't broken CASCADE and SET_NULL.

 Regarding stale related object caches, I'd do nothing special. Django
 currently doesn't refresh them, so any change here (for SET_NULL or
 CASCADE) would be backwards incompatible. And there is no guarantee the
 cache won't be stale again, when `_handle_sub_obj()` is called anyway.
 So this is a documentation issue with `Model.delete()` at best, since
 `QuerySet.delete()` always uses "fresh" data.

-- 
Ticket URL: <http://code.djangoproject.com/ticket/7539#comment:28>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to