#18682 closed Cleanup/optimization (fixed)
Make the deletion of stale content types safer
Reported by: | Aymeric Augustin | Owned by: | |
---|---|---|---|
Component: | contrib.contenttypes | Version: | 1.3 |
Severity: | Normal | Keywords: | |
Cc: | charette.s@…, speijnik | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
When a model is removed, syncdb
offers to remove its content type :
The following content types are stale and need to be deleted: myapp | mymodel Any objects related to these content types by a foreign key will also be deleted. Are you sure you want to delete these content types? If you're unsure, answer 'no'. Type 'yes' to continue, or 'no' to cancel:
While perfectly clear, this text is quite unhelpful, because there's no easy way to determine if any instance still has a foreign key to the content type.
To mitigate the risk of accidental cascade deletions -- sometimes you can be sure and wrong -- Django could tell the user how many related objects will be deleted, if any. This is similar to the admin's cascade delete UI, but only one level deep.
It would be quite embarrassing to admit why I'm filing this ticket. Let's just say the problem that shows up in the real world. Until we do something about this, I'll add on_delete=models.PROTECT
to all my foreign key to ContentType
in GenericForeignKey
definitions.
Attachments (1)
Change History (16)
comment:1 by , 12 years ago
Cc: | added |
---|
comment:2 by , 12 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:3 by , 10 years ago
Does this ticket need to be re-triaged to determine if it is still relevant in the era of native migrations and django1.7 ?
comment:4 by , 10 years ago
I believe it's still relevant as the behavior is the same with migrations. The only change is that the handler now uses the post_migrate
signal rather than post_syncdb
.
comment:5 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:6 by , 10 years ago
Working on this at EP14 sprint.
Displaying the object count alone is doable and I actually do have code doing just that already.
I guess it would be a good idea to actually show the number of objects grouped by their type/model.
Without doing that this will most likely always show a non-zero count, as permissions are always represented this way and
count towards that number.
Also, I believe that showing each individual object is a rather bad idea, think of thousands of objects there...
So right now, the output looks like this:
The following content types are stale and need to be deleted: app | a (29 objects remaining)
What I believe would be useful in this case, would be an output in the form of
The following content types are stale and need to be deleted: app | a - permission objects to be deleted: 3 - [...] objects to be delted: 26
This way things are pretty clear. The exact formatting might need to look different though.
comment:7 by , 10 years ago
Has patch: | set |
---|
Just attached the patch.
Formatting is obviously up for discussion and probably not optimal.
Example:
The following content types are stale and need to be deleted: app | a - auth | permission objects to be deleted: 3 - app | genericrel objects to be deleted: 26
comment:8 by , 10 years ago
Cc: | added |
---|
comment:9 by , 10 years ago
Needs documentation: | set |
---|---|
Needs tests: | set |
Patch needs improvement: | set |
comment:11 by , 9 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
comment:12 by , 8 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:13 by , 8 years ago
Needs documentation: | unset |
---|---|
Needs tests: | unset |
Owner: | removed |
Patch needs improvement: | unset |
Status: | assigned → new |
I have submitted a new PR: https://github.com/django/django/pull/6869
This PR uses the Collector to determine which objects would be deleted. This is the same collector that the admin uses to display which objects might be deleted, so it should be very thorough.
I have also changed the wording away from "need to be deleted" as I've been unable to find a basis for that claim of necessity. This was introduced in the confirmation added in #12339, which built upon #5177 in which the original (without confirmation) delete of stale types was added.
An example, as produced in the tests, now looks like this. Probably we can still improve the language:
Some content types in your database are stale and can be deleted. Any objects that depend on these content types will then also be deleted. The content types, and the dependent objects that would be deleted, are: - Content type for contenttypes_tests.Fake - 1 object of type contenttypes_tests.post: - post This list does not include data that might be in your database outside of Django's models. Are you sure you want to delete these content types? If you're unsure, answer 'no'.
I've run into this on more than one occasion. In fact I've had data loss because of this... though I suppose that probably doesn't qualify it as a data loss bug. Human error and all that. Still, would be nice to see it fixed.