13 May 23:11
DB Error handling in SQLAlchemy
From: Randall Nortman <rnsqlalchemy <at> wonderclown.com>
Subject: DB Error handling in SQLAlchemy
Newsgroups: gmane.comp.python.sqlalchemy.user
Date: 2008-05-13 21:15:22 GMT
Subject: DB Error handling in SQLAlchemy
Newsgroups: gmane.comp.python.sqlalchemy.user
Date: 2008-05-13 21:15:22 GMT
I'm evaluating SA to see if it's right for my needs, so this is sort
of a general question. Feel free to answer my questions by pointing
me to the right section of the docs -- I don't mind being told to
RTFM. But I've done a little RTFM'ing, at least in the introductory
level docs, and I haven't seen too much information about error
handling. I'm curious how SA handles this, especially transient
errors where a retry is the right thing to do. For example, in
several of my current sqlite apps (using bare DB-API), I get
occasional locking errors ("Database is locked"), which happens
sometimes with sqlite when there are concurrent processes accessing
the DB. The right thing to do is retry, but it's a real pain to write
*every* database operation with retry logic. Does SA handle retries
in cases like this automatically? (Admittedly, I think that more
recent versions of pysqlite handle locked DBs better than the somewhat
stale version I'm currently using, but I'm after the general principle
rather than trying to solve that particular problem.)
Aside from that, how in general does SA handle errors returned by the
underlying DB? Does it automatically do a rollback and/or reconnect
if necessary? If you're using the ORM layer is it able to still
figure out what objects/fields are dirty if an error was encountered
while trying to flush changes to disk? Is the programmer responsible
for differentiating between errors that indicate that a reconnect is
necessary and errors where the connection can continue to be used?
For example, if the DB throws a "connection lost" type of error, that
connection (and likely all the rest in the pool) must be re-opened,
and I want my DB layer to notice this and act appropriately --
including not losing track of what changes still need to be committed
at the ORM layer. Ideally, if the reconnect is successful, I never
(Continue reading)
RSS Feed