And more generally, you could always do something like:
try:
db.mytable.insert(**fields)
except Exception as e:
if type(e).__name__ == 'OperationalError':
pass
else:
raise e
Anthony
On Wednesday, September 7, 2016 at 3:47:48 PM UTC-4, Anthony wrote:
>
> According to the Python DB API specification, there should be a common
> set of exceptions <https://www.python.org/dev/peps/pep-0249/#exceptions>,
> and they should be exposed as attributes on the connection object
> <https://www.python.org/dev/peps/pep-0249/#connection-error>. Therefore,
> you should be able to do something like:
>
> try:
> db.mytable.insert(**fields)
> except (db._adapter.driver.IntegrityError, db._adapter.driver.
> OperationalError) as e:
> pass
>
> The above should catch the IntegrityError and OperationalError of any DB
> API compliant driver.
>
> Also, when making inserts or updates, if you don't care about the specific
> exception but just want to catch any database errors, the DAL API includes
> the following:
>
> db.mytable._on_insert_error = my_insert_error_handler
> db.mytable._on_update_error = my_update_error_handler
>
>
> Anthony
>
> On Wednesday, September 7, 2016 at 1:14:54 PM UTC-4, Joe Barnhart wrote:
>>
>> So my website runs under PostgresSQL today but will likely be switched to
>> MySql at some point in the future. My problem isn't with the DAL -- it
>> performs fine for what it does, insulating me very well from the nuances of
>> the SQL syntax for each engine.
>>
>> No, my problem comes from Exceptions. Each database engine defines its
>> own Exceptions within its driver. Even different drivers for the same
>> database engine (psycopg2 vs pg8000) come with different Exception trees.
>> If I want to be able to handle database exceptions (and who doesn't?) how
>> do I load and use the RIGHT set of Exceptions for each driver?
>>
>> When using the pg8000 driver for example, the Exceptions raised are all
>> of the form: "gluon.contrib.pg8000.ProgrammingError" or some such. Errors
>> from psycopg2 and the mysql drivers are similarly formed. I can't even use
>> this in a try-except block unless I first import gluon.contrib.pg8000. The
>> same is true for exceptions from all other database engines.
>>
>> Should we "alias" these database errors into a consistent tree inside
>> web2py? If we created a database exception tree inside web2py, and then
>> added to the database driver module a section that raised the corresponding
>> web2py Exception whenever a database exception was triggered, then we could
>> just catch ProgrammingError (from web2py) instead of
>> gluon.contrib.pg8000.ProgrammingError.
>>
>> Or, should I just put somewhere in the db definition of the models a line
>> like "import gluon.contrib.pg8000 as mydb" and then use
>> "mydb.ProgrammingError" throughout my code? I suppose I'd need to repeat
>> this in every module I create, and I create a LOT of modules....
>>
>> Anyway, is this a real problem or am I missing something obvious??
>>
>> -- Joe
>>
>>
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
