`manage.py migrate --noinput` should not delete stale modules

[uy-rrodriguez]

When manage.py migrate is called with --noinput or no-input, it deletes stale modules by default. This is not documented in the official documentation (​https://docs.djangoproject.com/en/2.2/ref/django-admin/#cmdoption-migrate-noinput) and it's a dangerous feature.

Other tickets have mentioned the addition of parameters like --force to force the deletion. I think either that approach or the use of other parameters should be preferred.

The ticket #25036 about deletion of stale content types was closed a long time ago without further comment, for which I assume the automatic deletion was discarded as dangerous.

The ticket #29556 about having --no-input in remove_stale_contenttypes automatically remove the stale content types was closed as fixed. I wonder whether the changes to fix that ticket affected the behaviour of the migrate command...

The tickets #29470 and #29026 comment about the output of the commands when --no-input is given. I think the output of migrate should list the stale elements without removing them.

I'm recording this bug with a Django version of 2.2 because we cannot use a newer release (issues with other libraries). But, as I haven't found any mention about this specific issue in other places, and the documentation part has not been changed between 2.2 and 3.1, I think the bug is still present (or at least the documentation is not specific about it).

Thank you for your time.

[Carlton Gibson]

Hi. Thanks for the report. I am going to say wontfix here initially, as it sounds to me like expected behaviour.

migrate synchronizes the database state with the current set of models and migrations — both adding and removing — and --noinput says Don't ask me for confirmation. If you're in any doubt as to the exact operations that will be performed you should use --plan to verify beforehand.

I hope that makes sense.

However, if you want to follow up with an exact example (with a sample project preferably) of where an operation is performed that you think it should not be I am happy to look at that to double check here.

Thanks again.

[uy-rrodriguez]

Hi Carlton, as you say it definitely depends on the desired behaviour.

My current use case is a software project with git branches for production (master), staging (test) and features. When new features are ready to be tested the staging branch is reset to master and the feature commits are merged into. From one "version" of the staging branch to another, the Django applications may change. I've identified the issue on this ticket when using --no-input in a new deployment of the staging branch where an app, not yet merged into master and so not existent in this new staging branch, was detected as stale and removed from the database. In this case we have lost the testing data stored by the staging branch that included such app. Of course, this is all test data and so it's not a big issue if it gets lost, we could also have a completely clean server each time a branch is deployed for testing, but that's not the point.

Personally, I wasn't expecting Django to remove the stale elements and I think other people may encounter the same surprise.

I think this ticket could be reopen at least to signal that the documentation could be updated to clarify how migrate behaves when --no-input is given.

Replying to Carlton Gibson:

Hi. Thanks for the report. I am going to say wontfix here initially, as it sounds to me like expected behaviour.

migrate synchronizes the database state with the current set of models and migrations — both adding and removing — and --noinput says Don't ask me for confirmation. If you're in any doubt as to the exact operations that will be performed you should use --plan to verify beforehand.

I hope that makes sense.

However, if you want to follow up with an exact example (with a sample project preferably) of where an operation is performed that you think it should not be I am happy to look at that to double check here.

Thanks again.