Opened 4 years ago

Last modified 4 years ago

#32264 new Cleanup/optimization

Run database checks by default in some scenarios

Reported by: Adam Johnson Owned by: nobody
Component: Core (System checks) Version: 3.1
Severity: Normal Keywords:
Cc: Simon Charette Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

#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 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.

Change History (1)

comment:1 by Simon Charette, 4 years ago

Triage Stage: UnreviewedAccepted

Enable --database all to allow specifying all the database aliases on the command line.

I wonder if we could make --database without a value alias to --database __all__ instead. Maybe it's not a good idea due as might cause an issue similar to #31621?

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.

Makes sense to me.

Version 1, edited 4 years ago by Simon Charette (previous) (next) (diff)
Note: See TracTickets for help on using tickets.
Back to Top