catch DatabaseError instead of OperationalError in makemigrations check_consistent_history()

[Piotr Kubiak]

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.

​Proposed fix, I am happy to prepare a PR.

[Jacob Walls]

Thanks for the ticket. I'm concerned the wide catch would hide legitimate programming errors from other sources (e.g. introspection syntax). This appears to be a niche use case; you could work around it at the project level by overriding the makemigrations command.