#12339: ContentType update could cascade deletes to generic foreign keys, 
causing
data loss
-----------------------------------+----------------------------------------
          Reporter:  kcarnold      |         Owner:  nobody                     
 
            Status:  closed        |     Milestone:                             
 
         Component:  Contrib apps  |       Version:  1.1                        
 
        Resolution:  duplicate     |      Keywords:  contenttype, delete, 
cascade
             Stage:  Unreviewed    |     Has_patch:  0                          
 
        Needs_docs:  0             |   Needs_tests:  0                          
 
Needs_better_patch:  0             |  
-----------------------------------+----------------------------------------
Changes (by kmtracey):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => duplicate
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Starting with "Imagine that you change the name of a model" we're off in
 territory that Django does not yet claim to support: schema migration.
 Given that, what it looks like to Django when you change the name of a
 model is that the old model has been deleted. Django then correctly
 deletes the content type for that model, and yes that will cascade to any
 rows in other tables that referenced that content type.  You do not lose
 the admin log, but you lose any entries in it that refer to the old model.
 To omit the cascade would be wrong, because that would leave pointers to
 nowhere hanging around. The current behavior is correct for the case where
 a model has been deleted.  True, it does not account for the case where
 you are renaming the model, not actually deleting it, but that is not a
 problem that will be fixed individually. The correct way to fix that
 problem would be to implement general schema migration, which is covered
 by #5934. Presumably a good schema migration would handle updating the
 content type on a rename instead of deleting it, and so avoid the cascade
 delete (though I don't know the details of how any of the existing
 external apps that do migration handle this, I've not had any need to use
 them). At any rate I'm going to close this as a duplicate of the migration
 ticket, since this won't be "fixed" except as part of the larger effort to
 incorporate migrations into the base.

-- 
Ticket URL: <http://code.djangoproject.com/ticket/12339#comment:1>
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 [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-updates?hl=en.


Reply via email to