'makemigrations' is a code generator, not a "do it right all the time" wizard. There are many situations where it doesn't do what the user intended. Users are ultimately responsible for the contents of migration files and should read them before applying them, and also use sqlmigrate to see what the underlying SQL is.
I think our "workflow" section could make this clearer: https://docs.djangoproject.com/en/3.0/topics/migrations/#workflow I am unsure that adding warnings or errors will force users to pay more attention. Often users run without warnings displayed. On Fri, 12 Jun 2020 at 12:41, Jason Johns <jjohns98...@gmail.com> wrote: > Should Django output a warning and/or require a prompt when a DeleteModel > or RemoveField are to be executed when applying migrations? > > Over at the pythondev slack group, a user wanted to rename a model to > another name, and wasn't aware of the `db_table` attribute in Model Meta. > So a new model was created, the old one removed. Then a migration was made > and applied... only to delete the data on the staging environment. This > user was also unaware of the typical three step migration process > recommended for removing a model or field, and made the statement that > there should have been a prompt during migrate that data loss was a > possibility. > > This got me thinking. Googling around seems to suggest this experience of > running a delete migration is a somewhat common footgun because the > implications are not as explicit as Python warnings and exceptions. As a > result, it might be beneficial for migrate to have some tweaks to attempt > to reduce surprise. > > How about this: > > 1. Migrate checks if any executions of migrations.DeleteModel or > migrations.RemoveField are included in the migrations being applied > 2. If so, output a warning message about a table being dropped or > column being deleted and that data loss will occur > 3. Output a yes/no input prompt asking if the user has made a data > migration or is aware and acknowledges the risk > > > Is this something that would fit in with the overall philosophy of > Django? To be honest, I'm undecided about this, but this may be my own > biased feelings that this should be implicit in the developer's mind when > considering removing columns and tables. But then again, I have been > burned by this in a toy project. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/e4af0410-7eab-4431-8c56-5094d9498b92o%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/e4af0410-7eab-4431-8c56-5094d9498b92o%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Adam -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM0ROmXKTaZ7fuw7cvXLLRk8AbrWw1EhcQMssOofpYGKGA%40mail.gmail.com.
