Re: Proposal - Warn user when creating or applying a delete migration?

It's easy enough to read the output before you migrate. It's pretty darn hard to accidentally delete an entire Model. It'd have to be a new or obscure Model with no references in your Views, no ForeignKeys to it, etc etc. Deleting a Field accidentally on the other hand is pretty easy to do. I

Re: Add verbosity option to manage.py checks that outputs which checks are ran

This really feels like a "who watches the watchmen" problem. Where does this problem stem from? Are you conditionally registering a check function? It would be better in that case to move the conditionality into the check body. On Fri, 12 Jun 2020 at 15:33, Gordon wrote: > The underlying

Re: Add verbosity option to manage.py checks that outputs which checks are ran

The underlying problem that I want to solve is a way to fail a CI job if checks for an app don't run. The only approach I currently see that would accomplish that is by using a custom tag for every project that could fail with the invalid tag error - but this feels wrong. Would you be in

Re: Proposal - Warn user when creating or applying a delete migration?

I appreciate the feedback! I do agree with you, Adam, that this may not be something that would strictly be Django's responsibility, but I also feel that if a thing is causing a number of footguns, regardless if its primarily the user's fault, Django is getting the blame. I do like your

Re: Proposal - Warn user when creating or applying a delete migration?

I think opening a migration file in the users $EDITOR could be a good flag to add, but I would be wary of making it a default behaviour. I can see it being useful in some situations but annoying in others. I made a ticket for changing the output: https://code.djangoproject.com/ticket/31700 >

Re: Proposal - Warn user when creating or applying a delete migration?

That output change would be useful, but not accessible. Perhaps we should also use "+" for creative and "-" for destructive operations? We could also open the generated migration file in the user's $EDITOR, if the terminal is interactive. This would be a nice usability improvement for use of

Re: ./manage.py settings

There was a GSoC proposal this year for a SecretsManager that could conceivably make what you suggest possible. Wasn't accepted though. Not sure if

Re: Proposal - Warn user when creating or applying a delete migration?

Hi, > 3. Output a yes/no input prompt asking if the user has made a data > migration or is aware and acknowledges the risk Migrations are often applied non-interactively during some kind of automated deployment step. So this behaviour would have to be somehow optional. Either it has to

Re: Proposal - Warn user when creating or applying a delete migration?

Fully agree, I would be against adding a y/n prompt. However we could make the `makemigrations` output more noticeable if it contains destructive operations? We could make the this line[1] output red text on destructive operations, yellow on maybe destructive (like altering a type), and green

Re: Proposal - Warn user when creating or applying a delete migration?

'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

Re: ./manage.py settings

Hi, Just a thought that came to my mind: It would be useful to have a command that dumps the run-time settings, but automatically replaces secrets with dummy values. I think this should not be too hard to do for Django's own secret settings, and maybe it can also be done for some known common

Proposal - Warn user when creating or applying a delete migration?

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

Re: Defaulting to use BigAutoField in models

I haven't thought this through, but maybe it's possible to restrict the change to inside AutoField, rather than create a new field class. If its db_parameters() method / db_type() could receive enough context from the migration history, it could potentially determine its own database type. For

Re: Defaulting to use BigAutoField in models

> I think we should restrict the setting between normal and big auto fields > only. Allowing UUID's would be changing the type, with the potential for > havoc with code incompalities throughout django. It's also not possible to > migrate tables over to the new type. That’s a really good point,

Re: ./manage.py settings

It wasn't discussed indeed, nice command, thank you ! -- 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