Make destructive commands such as migrate/createcachetable interactive by default to prevent accidental executions

[ankitsmt211]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

User confirmation prompt for desctructive commands migrate and createcachetable, which can be bypassed using -no--input flag

Problem

python manage.py migrate 

is a subset of

python manage.py migrate --plan

A preview command is walking into destructive territory which has no safety rails, accidentaly execution can lead to unnecessarily painful experience. Not to mention explicit consent/cofirmation is a UX for destructive commands in place which some of the management commands already follow.

Request or proposal

proposal

Additional Details

This proposal is evolved from initial discussion, here's more information #163

Note: flush/collectstatic already follow proposed pattern

Implementation Suggestions

User executes:

python manage.py migrate

Prompted with: "This command can modify database. Are you sure you want to proceed ? [Y/N]

User executes:

python manage.py migrate -no--input

Migration is applied

Similar pattern will be followed for createcachetable

[github-actions]

Thank you ankitsmt211 for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[ankitsmt211]

CC: @codingjoe

[frankwiles]

I get that this would make it safer, but that's a fairly large UI change for people who have a bunch of automation already in place for migrations. Perhaps we should consider a safemigrate command or env var or something that would turn on this new behavior instead.

[ankitsmt211]

I get that this would make it safer, but that's a fairly large UI change for people who have a bunch of automation already in place for migrations. Perhaps we should consider a safemigrate command or env var or something that would turn on this new behavior instead.

Agreed , codingjoe also mentioned something similiar in original issue.

This will probably undergo the deprecation cycle
The command is used in orchestration and requires a careful update path.

I'd root for configuration/env path and a deprecated warning. Thoughts on introducing new django settings ?, perhaps something like this rolled out in phases.

ENABLE_SAFE_MIGRATION=True
ENABLE_SAFE_CREATE_CACHE_TABLE=True

Eventually making these commands safe by default.

A new command for migrate may not solve the issue imo.

[codingjoe]

I get that this would make it safer, but that's a fairly large UI change for people who have a bunch of automation already in place for migrations. Perhaps we should consider a safemigrate command or env var or something that would turn on this new behavior instead.

@frankwiles Yes, I thought so too. Yet I still believe the change is excellent. We just have to find a clever way to deprecate the old way. So I guess it's more a “how”, not an “if”, right?

Now again falling back on my previous apt-get example, we can follow their lead and just add new command and deprecate the old one. From apt-get to apt. Or in this case… don't know, migrate to applymigrations? Something consistent with makemigrations and maybe less ambiguous than migrate.

Or… bear with me here, command groups:

django migrations apply

🤯

It's called Django CLI now anyway… so…

[MarkusH]

python manage.py migrate --plan is the legacy version of python manage.py showmigrations --plan and ought to be removed. I guess, I never go around doing that ...

[codingjoe]

python manage.py migrate --plan is the legacy version of python manage.py showmigrations --plan and ought to be removed. I guess, I never go around doing that ...

There's a showmigrations command? 🙄 You never stop learning new things. 🤣

That being said, I am still all for bulletproofing migrate. Maybe even running a migration without ever committing the transaction, to dry-run against your actual schema and data.