#36774: catch DatabaseError instead of OperationalError in makemigrations
check_consistent_history()
-------------------------------------+-------------------------------------
Reporter: Piotr Kubiak | Type:
| Cleanup/optimization
Status: new | Component:
| Migrations
Version: 6.0 | Severity: Normal
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/36774>
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 visit
https://groups.google.com/d/msgid/django-updates/0107019ae99f235e-5df41066-1ecd-4348-ad09-51f3debbc889-000000%40eu-central-1.amazonses.com.
