#36774: catch DatabaseError instead of OperationalError in makemigrations
check_consistent_history()
-------------------------------------+-------------------------------------
     Reporter:  Piotr Kubiak         |                    Owner:  (none)
         Type:                       |                   Status:  closed
  Cleanup/optimization               |
    Component:  Migrations           |                  Version:  6.0
     Severity:  Normal               |               Resolution:  wontfix
     Keywords:                       |             Triage Stage:
                                     |  Unreviewed
    Has patch:  1                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  1                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Comment (by Natalia Bidart):

 I agree with the `wontfix` status. The goal of the existing
 `OperationalError` catch is narrow: avoid blocking `makemigrations` when
 the database is simply not reachable. It was never meant to ignore all
 database-related failures. This is what #31504 solved.

 Catching `DatabaseError` is too broad, and worse backwards incompatible.
 It wraps real programming errors, backend bugs, bad introspection queries,
 and misconfigured schemas. Swallowing those would hide exactly the signals
 developers need when something is actually wrong. That is a regression
 risk in a core command.

 `OperationalError` hits the intended scope without masking unrelated
 issues. Broadening it would change the contract of `makemigrations` from
 "skip the consistency check when the DB is down" to "ignore any error that
 happens to come from the DB layer".

 The reported setup is valid but, IMHO, niche. Projects with custom
 triggers can override the command locally because they understand their
 own failure modes. Django cannot safely broaden the catch in a way that
 preserves predictable error reporting for the common case.

 Keeping this as `wontfix` keeps the boundary clear and avoids silent
 failures in migrations.
-- 
Ticket URL: <https://code.djangoproject.com/ticket/36774#comment:4>
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/0107019aeb2c4064-bfc35784-d9be-46e3-adab-b0fd7f3e7cd8-000000%40eu-central-1.amazonses.com.

Reply via email to