#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:  Design     |      Has patch:  0
  decision needed                    |    Needs tests:  0
    Needs documentation:  0          |  Easy pickings:  0
Patch needs improvement:  0          |
                  UI/UX:  0          |
-------------------------------------+-------------------------------------

Comment (by absurdhero):

 I have a specific real-world use case which I can describe. My web
 application has an accompanying daemon that inserts data into the database
 from another source and it wakes up periodically to do its work. If the
 database has restarted while it was asleep or if there is a connection
 problem, the next query will raise `OperationalError` per PEP 249. The
 daemon catches this exception and goes back to sleep so that it may retry
 later. It cannot catch all `DatabaseError` subclasses or it would gobble
 up important `DataError` or `ProgrammingError` exceptions which should be
 catastrophic errors and do not warrant retrying later.

 This use case would be satisfied if `OperationalError` were separately
 wrapped so that intermittent (non-programmer) errors could be handled
 differently.

 Another option I see is providing the ability to disable cursor exception
 wrapping for users who care to deal with their database driver's exception
 behavior directly. I'm not convinced that Django should provide a complete
 and total database abstraction layer and driver abstraction layer for all
 purposes. Covering up errors and losing important exception information is
 not always acceptable but, as xiaket stated, handling every driver's
 exceptions uniformly may not be feasible. The only solution is to allow
 users to disable this kind of deep driver abstraction while keeping the
 database model abstraction. If I understand correctly, this is currently
 not supported.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/15901#comment:5>
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.

Reply via email to