Opened 10 years ago
Closed 8 years ago
#24865 closed New feature (fixed)
Add a management command to remove stale content types
Reported by: | Kay | Owned by: | |
---|---|---|---|
Component: | contrib.contenttypes | Version: | dev |
Severity: | Normal | Keywords: | stale contenttypes |
Cc: | Kay, emorley@… | 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
This patch creates a new method remove_contenttypes
that, when called from a migration, will programmatically remove the stale content type.
Diff: https://github.com/django/django/compare/master...Protosac:removalUtility
Change History (20)
follow-up: 2 comment:1 by , 10 years ago
Component: | Uncategorized → contrib.contenttypes |
---|---|
Needs documentation: | set |
Needs tests: | set |
Summary: | Adding a feature to programmatically remove stale content types → Add a feature to programmatically remove stale content types |
Triage Stage: | Unreviewed → Accepted |
Version: | 1.7 → master |
comment:2 by , 10 years ago
Replying to timgraham:
Could you please send a pull request with tests and documentation? You may find the patch review checklist helpful.
I've looked the specs over and I'm not sure this warrants a test. The current Django tests for update_contenttypes
already test for interactive. All this change does is automatically respond to it's prompt in the very same way the test_interactive_true
does.
def test_interactive_true(self): """ interactive mode of update_contenttypes() (the default) should delete stale contenttypes. """ management.input = lambda x: force_str("yes") with captured_stdout() as stdout: management.update_contenttypes(self.app_config) self.assertIn("Deleting stale content type", stdout.getvalue()) self.assertEqual(ContentType.objects.count(), self.before_count)
As for documentation I was considering placing it in the contenttypes.txt and adding a Management section to describe the force_remove
argument and remove_contenttypes
method. If that's an inappropriate place, please make a recommendation. Thanks again.
comment:3 by , 10 years ago
Tests would ensure that the remove_contenttypes()
function performs the job it's expected to do (deleting content types for the given app
).
For docs, I'd suggest to add a "Utilities" section which documents remove_contenttypes()
. No need to document the update_contenttypes()
method -- that should remain a private function in my opinion.
comment:4 by , 10 years ago
I think remove_contenttypes()
should remain private as well. It's way too easy to loose data when using that function. I'd put the respective documentation for that method into the function's docstring.
comment:5 by , 10 years ago
Patch needs improvement: | set |
---|
comment:6 by , 10 years ago
Markus, can you elaborate on the data loss concerns? I guess it's about the possibility of delete cascades which is why interactive prompts were originally added in #12339. I don't think there's much value in completing this ticket if it isn't a public API. I'd think documentation that explains the data-loss considerations would do more to educate users than keeping the function private would. If you have another idea on how to address the use case in #24820 I'm open to alternatives.
comment:7 by , 10 years ago
Tim, neither patch is guaranteed to work when a user has not applied all contenttypes
migrations, as the model used inside the update_contenttypes
is from the global apps, not from the latest applied migration state (see #24100 for that).
Anyway, I'm ok with making it a public API if we put a .. warning::
box around the docs and state the potential data loss due to cascading.
comment:8 by , 10 years ago
Cc: | added |
---|
comment:9 by , 10 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
comment:10 by , 10 years ago
Needs documentation: | unset |
---|---|
Needs tests: | unset |
Patch needs improvement: | unset |
Triage Stage: | Ready for checkin → Accepted |
comment:11 by , 9 years ago
Cc: | added |
---|
comment:12 by , 9 years ago
Patch needs improvement: | set |
---|
comment:13 by , 9 years ago
Markus and I chatted in IRC and came up with the idea of moving stale content types deletion out of the post_migrate
signal update_contenttypes
function and into a separate remove_stale_contenttypes
management command. This would default to interactive=True
but could be called with call_command('remove_stale_contenttypes', interactive=False)
to delete without a prompt.
How does this sound?
comment:14 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
I started working on the management command described in the previous comment: PR
comment:15 by , 9 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
I'd welcome someone continuing where I left off here.
comment:16 by , 9 years ago
I think that the other side of not removing stale content types for fear of data loss is leaving stale GenericForeignKey
s, which will break when accessed (see #25931). Hard to say which is worse.
I think perhaps adding a switch to migrate is better: --remove_stale_contenttypes
or --keep_stale_contenttypes
, and if none are present then default to current interactive behaviour.
comment:17 by , 9 years ago
I doubt it's acceptable to add a contrib app specific option to migrate
.
comment:18 by , 8 years ago
Patch needs improvement: | unset |
---|---|
Summary: | Add a feature to programmatically remove stale content types → Add a management command to remove stale content types |
I completed my old PR.
comment:19 by , 8 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
Could you please send a pull request with tests and documentation? You may find the patch review checklist helpful.