Repository navigation
sqlobject should raise exceptions from dberrors only #5
Description
This could be a running list of them as I find them.
- raw Exception in dbconnection.py
sqlobject/sqlobject/dbconnection.py
Line 390 in 49943d5
- Add executeEntry pattern to firebirdconnection.py https://github.com/sqlobject/sqlobject/blob/49943d5539d0424811f772ffc81a8cdc1902e252/sqlobject/firebird/firebirdconnection.py
- Add executeEntry pattern to mssqlconnection.py https://github.com/sqlobject/sqlobject/blob/49943d5539d0424811f772ffc81a8cdc1902e252/sqlobject/mssql/mssqlconnection.py
- Add executeEntry pattern to rdbhostconnection.py https://github.com/sqlobject/sqlobject/blob/49943d5539d0424811f772ffc81a8cdc1902e252/sqlobject/rdbhost/rdbhostconnection.py
- Add executeEntry pattern to sybaseconnection.py https://github.com/sqlobject/sqlobject/blob/49943d5539d0424811f772ffc81a8cdc1902e252/sqlobject/sybase/sybaseconnection.py
- Add executeEntry pattern to maxdbconnection.py https://github.com/sqlobject/sqlobject/blob/49943d5539d0424811f772ffc81a8cdc1902e252/sqlobject/maxdb/maxdbconnection.py
- Convert exceptions from fetchall in dbconnection._queryAll
sqlobject/sqlobject/dbconnection.py
Line 476 in 49943d5
- Convert exceptions from fetchone in dbconnection._queryOne
sqlobject/sqlobject/dbconnection.py
Line 446 in 49943d5
- Convert exceptions from fetchall in dbconnection._queryAllDescription
sqlobject/sqlobject/dbconnection.py
Line 463 in 49943d5
Activity
drnlm commentedon Oct 27, 2016
Does this need to be fixed? Currently, this is an undocumented feature, and, as autoCommit is initialised from a Boolean, it requires manually poking at the dbconnection.autoCommit to even hit this code path. It is used in the test suite, so this might be something that can be treated as an internal implementation detail.
If this is something we should change, which exception should it raise (reading PEP249, InterfaceError is probably the best fit)?
phdru commentedon Oct 27, 2016
If 'this' is the entire ticket, then yes, it will be a major enhancement to protect SQLObject users from database-specific exceptions and instead raise those of SQLObject.
If 'this' is one particular exception than I think it could be left out. But I'd prefer it to be IntegrityError, ProgrammingError or NotSupportedError.
drnlm commentedon Oct 28, 2016
"this" was referring to the listed exception, since it's the only place that sqlobject raises a raw exception. It is simple to change it to something else, it's just a matter of what it should be,
For the other cases, it looks like the sqlite, mysql and postgres connections will do the right thing in _executeRetry. The other connectors don't.
The calls to fetchone and fetchall in dbconnection._queryAll, dbconnection._queryOne and dbconnection._queryAllDescription will also need conversion logic, as these can throw an exception if the query returns nothing psycopg2 returns InterfaceError or ProgrammingError depending on the exact problem , and the other dbapi implementations I've looked at return either or just hide the error and return an empty set of results. SQLObject should probably pick one to consistently retutn (ProgrammingError?)
I've edited the original isse to add a more complete list of tasks.
phdru commentedon Oct 28, 2016
That's exactly the concern of the issue.