On Tuesday, September 13, 2016 at 11:25:29 AM UTC-7, Joe Barnhart wrote: > > Ooooh...... I like that. I may think of that idea myself! Good job. > > -- Joe >
If going this way, I think I'd base it on Anthony's comment. /dps > On Tuesday, September 13, 2016 at 6:33:54 AM UTC-7, > tim.n...@conted.ox.ac.uk wrote: >> >> It may be a bad move, but I defined IntegrityError in a model, so it can >> be nice and terse everywhere else: >> IntegrityError = idb._adapter.driver.IntegrityError >> >> Where I have two different databases, I just added it to the database >> objects: >> db.IntegrityError = db._adapter.driver.IntegrityError >> idb.IntegrityError = idb._adapter.driver.IntegrityError >> >> Allows for nice readable except statements >> >> >> On Wednesday, 7 September 2016 20:47:48 UTC+1, 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.
