#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 Piotr Kubiak):
Replying to [comment:1 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.
Are you open for discussion?
I understand your point, but is the purpose of
`check_consistent_history()` really to raise on introspection syntax
errors?
If it is, that is not clear. Is it even possible that
`check_consistent_history()` will raise `ProgrammingError` or any other
specific error? Maybe it's just a side effect.
For me, `check_consistent_history()` is an optional check. #31504 gives a
rationale that if database is **not available**, skip this check. I think
my use case may be niche, but it is valid.
--
Ticket URL: <https://code.djangoproject.com/ticket/36774#comment:3>
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/0107019ae9e1430b-b8c850a1-d975-4fce-bbb2-116c35f6c9c5-000000%40eu-central-1.amazonses.com.
