#15901: Django should wrap all PEP 249 exceptions in db.utils
-------------------------------------+-------------------------------------
Reporter: xiaket | Owner: nobody
Type: New | Status: new
feature | Component: Database layer
Milestone: | (models, ORM)
Version: 1.3 | Severity: Normal
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Changes (by carljm):
* stage: Design decision needed => Accepted
Comment:
As a point of reference, SQLAlchemy wraps all the PEP 249 exceptions
individually - see `help(sqlalchemy.exc)`.
The reasons given here for not doing this in the Django ORM seem a bit
handwavy to me. Since all PEP 249 exceptions (but one) should inherit from
`DatabaseError` in a proper DB API driver, and we already catch and wrap
`DatabaseError` in all the backends, we are already wrapping everything
anyway and papering over implementation differences in the backends; only
we're doing it in a way that hides a lot more information than we'd need
to (we hide the distinction between `OperationalError`,
`ProgrammingError`, `InternalError`, `DataError`, and `NotSupportedError`
- they all end up as `django.db.utils.DatabaseError`).
Adding the appropriate three-line "except-raise" clauses in `execute` and
`execute_many` of each backend's `CursorWrapper` to wrap each of these
individually (no need for smart introspection of the contents or caring
about how they differ from backend to backend, just wrap and pass along
the arguments exactly as we do now with `DatabaseError`) would not add a
significant maintenance burden and would hide a lot less information than
we do now. If backends are inconsistent in when they use the various
errors, or what arguments they pass to them, fine: the inconsistency would
be no worse than it is now (application code could still catch
`DatabaseError` if it doesn't care about the distinction), but code that
does care about the distinction, needs to support more than one backend,
and knows what the backends it cares about actually do, would be a lot
easier to write.
Checked this with Jacob in IRC - moving back to Accepted.
--
Ticket URL: <https://code.djangoproject.com/ticket/15901#comment:6>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
