#29556: remove_stale_contenttypes --noinput should non-interactively delete
stale
content types
------------------------------------------------+------------------------
Reporter: Jon Dufresne | Owner: nobody
Type: New feature | Status: new
Component: contrib.contenttypes | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------------+------------------------
I recently noticed that `remove_stale_contenttypes --noinput` does not
delete stale content types. It simply does nothing and returns,
effectively making the command a noop. I had been absentmindedly using
this command for months not realizing it wasn't useful. To use this
command to delete content types, one must run the command in interactive
mode and answer "yes" at the prompt. This makes it difficult to use when
managing a large number of Django sites where it is impractical to run
interactive commands.
The previous post_migrate signal, when combined with -`-noinput`, did not
delete content types due to data loss concerns. However, now that
`remove_stale_contenttypes` is a standalone management command, I think
the data ramifications are much more clear and less likely to cause
unwanted data loss.
I suggest one the following:
- (My preferred) Change `remove_stale_contenttypes --noinput` to remove
stale content types instead of doing nothing. I think this is a more
intuitive behavior given the arguments. The combination of arguments would
stop being a noop and provide useful behavior to projects managing a large
number of Django sites. However, I recognize this has some backwards
compatibility concerns. The argument would change from doing nothing to
deleting database records.
- Add a new argument `--force` that would assume the answer "yes" for all
prompts. I think this is less optimal as it introduces an argument that
doesn't need to exist if we could modify the behavior of `--noinput`.
If the backward compatibility concerns are too much, perhaps it could be
introduced in stages:
Next release:
- Issue a deprecation warning when using `remove_stale_contenttypes
--noinput`, state that it will delete content types in a future version.
- Add `--force` arguments so project admins can delete stale content types
in a non-interactive fashion.
After a deprecation period:
- Change `remove_stale_contenttypes --noinput` to delete content types.
- Deprecate, and eventually remove, `--force`.
Prior tickets to consider:
- #24865 -- Add a management command to remove stale content types
- #25036 -- `manage.py migrate --noinput` does not delete stale content
types (refers to old post_migrate signal)
Code of `remove_stale_contenttypes` showing that it is a noop:
https://github.com/django/django/blob/338f741c5eb6b91118f6a6b7c34b5e9b47a5661d/django/contrib/contenttypes/management/commands/remove_stale_contenttypes.py#L36-L72
--
Ticket URL: <https://code.djangoproject.com/ticket/29556>
Django <https://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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/052.950f0abb3d7060b6497edc807190d8c8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
