#32264: Run database checks by default in some scenarios
-------------------------------------------------+------------------------
               Reporter:  Adam (Chainz) Johnson  |          Owner:  nobody
                   Type:  Cleanup/optimization   |         Status:  new
              Component:  Core (System checks)   |        Version:  3.1
               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                      |
-------------------------------------------------+------------------------
 #31055 disabled database checks by default in order to make tests that
 don't set up certain databases pass. This is great but it leads to a
 couple problems:

 * Even with `manage.py check --deploy` as we suggest in the deployment
 checklist, the database configuration checks won't be run now.
 * Users need to name all their database aliases on the command line if
 running `manage.py check`. Even if `--database default` was added to a
 deployment script early in the project, it's likely to be forgotten when
 adding a new database connection.
 * Database checks *are* run during `manage.py migrate`, but that output
 can be long if several migrations are executed with a higher verbosity
 level, so any non-error messages are likely to be missed.

 I write this as I'm trying to figure out what to do with the [https
 ://django-mysql.readthedocs.io/en/latest/checks.html Django-MySQL database
 checks] which show several warnings to users to improve their database
 configuration. I now realize that they will mostly be disabled for users
 on Django 3.1.

 My suggestions would be:

 * Enable `--database __all__` to allow specifying all the database aliases
 on the command line.
 * Make `--deploy` imply `--database __all__` . Since this is normally run
 around the same time as `migrate`, it shouldn't be an issue to connect to
 all databases at that point (and was the behaviour of Django <3.1 anyway).
 * Make `runserver` run database checks for all connections. This will help
 catch issues in development.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/32264>
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.a216477076548b15ca12e6239d5eb409%40djangoproject.com.

Reply via email to