Opened 17 years ago
Closed 17 years ago
#5177 closed (fixed)
ContentType should purge orphaned models
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Contrib apps | Version: | dev |
Severity: | Keywords: | ||
Cc: | treborhudson@… | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
When working with models there are often times when one refactors model class names which leaves orphaned content types in the database. Content types should clean themselves when they notice an app no longer contains models in the database.
Attachments (4)
Change History (11)
by , 17 years ago
Attachment: | ctremove.diff added |
---|
comment:1 by , 17 years ago
See: http://groups.google.com/group/django-developers/browse_thread/thread/c0a99afe82d4eaa8
The first patch works but I haven't tested fully. I had assumed I would also have to figure out how to manage the various permissions tables but it seems to be taking care of itself. I looked to see if the delete() on the ContentType object had some trickery to update the permissions but didn't find anything.
This doesn't remove the orphaned model tables themselves either, which is probably good... the idea for this patch was to avoid having to delete rows in the contenttype and various permissions tables, dropping a table is easy enough.
comment:2 by , 17 years ago
Needs documentation: | set |
---|
Just an update on this patch: I figured out the "trickery" in that Permissions has a FK to ContentType and therefore takes care of itself when a content type is deleted. Nice.
This patch accomplishes what I think it should...
- If a model in an installed app gets orphaned, it removes that content type.
- If a content type is renamed, it removes the old one and installs the new one.
- It does not track or understand a renaming happened and migrate permissions or anything else. That's a bit outside the scope of this, I think.
I'll work on adding docs and test cases if I can.
-Rob
comment:3 by , 17 years ago
Patch needs improvement: | set |
---|---|
Triage Stage: | Unreviewed → Accepted |
I like this patch and assuming all the concerns below are not real problems, it's close to reday. A few small things to fix and one large thing to ponder:
- create_contenttypes() now really needs a docstring, because it's not just creating new content types. It's also cleaning up old ones. Looks like it's a bit fiddly to move the "remove" processing out from the "create" loop, so it'll have to stay as one method. But at least document what it's doing in a broad way.
- We're strong believers in the English language and full sentences. The comment you've got to needs an initial capital and final full stop.
- The AUTHORS file is in alphabetical order by surname. Try to find where your name belongs (hint: it's not at the end).
- Do you need to get app_label from the models? What happens if a model has Meta.app_label set?
Now here's the big problem: is this a safe thing to do? I haven't followed through all the code, but I would guess it's not impossible for models in different locations to have the same value for their Meta.app_label attribute. I'm not sure if Django works well in that case, or if django.core.management sorts that out and groups things properly (I suspect not), or if it's something we want to support. But right now it might be possible. If so, that would mean you could end up calling create_contenttypes() multiple times for the same app_label.
At the moment, I suspect that just means not as much cleaning up gets done, so it fails safely (no still-valid data is deleted), right? I think this bears some thinking about; I don't know the answer yet, because it just occurred to me when I was reviewing the patch.
Not sure it's going to really be possible to test this, since the ContentTypes table is flushed for each new test anyway. If you can come up with something, great. However, I can't think of how to do it offhand.
What docs do you think are necessary? A quick observational note in the contrib apps docs? It's almost doing the natural thing and could pass without comment. By all means, write whatever you think is good, but I wouldn't hold back the patch if you think there's nothing worth saying.
by , 17 years ago
Attachment: | ctremove.2.diff added |
---|
Fixing points 1 through 3 from Malcolm. Point #4 will need more time to ponder.
comment:4 by , 17 years ago
Triage Stage: | Accepted → Design decision needed |
---|
Discussion and a design decision needed request regarding Malcolm's point 4 above posted to the developers list here:
http://groups.google.com/group/django-developers/browse_thread/thread/60de62f7a1b05f17/
Marking as design decision needed.
by , 17 years ago
Attachment: | ctremove.4.diff added |
---|
comment:5 by , 17 years ago
Triage Stage: | Design decision needed → Ready for checkin |
---|
Per Adrian and Jacob's suggestion, changing method name to update since it's now doing more than creating.
comment:6 by , 17 years ago
Needs documentation: | unset |
---|---|
Patch needs improvement: | unset |
comment:7 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
First attempt at a patch for this. This is a diff from git so this may need tweaking...