Opened 2 hours ago
Last modified 75 minutes ago
#36774 closed Cleanup/optimization
catch DatabaseError instead of OperationalError in makemigrations check_consistent_history() — at Initial Version
| Reported by: | Piotr Kubiak | Owned by: | |
|---|---|---|---|
| Component: | Migrations | Version: | 6.0 |
| Severity: | Normal | Keywords: | |
| Cc: | Piotr Kubiak | Triage Stage: | Unreviewed |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | yes | UI/UX: | no |
Description
This is a follow up to #31504.
I am proposing a change to the way that the check_consistent_history() behaves when an error occurs while accessing the database during the makemigrations command. Currently, only the OperationalError is caught and silenced.
In my setup, the database is accessible (I am able to connect), but database administrator implemented custom triggers that limit access for specific users. This makes my connection attempts fail with DatabaseError rather than OperationalError. But since the former is not silenced, makemigrations effectively requires a fully working database setup, which according to #31504 should not be necessary.
The original issue states that Django should "fail gracefully if the connection to the database isn't available." Therefore, I suggest catching the more general DatabaseError instead of OperationalError, as it covers more cases of database unavailability.
I am happy to prepare a PR.