Description

sigmavirus24

opened on Dec 26, 2014

Issue body actions

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

  raise Exception('Object used outside of a transaction; '

• 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

  value = c.fetchone()

• Convert exceptions from fetchone in dbconnection._queryOne

  sqlobject/sqlobject/dbconnection.py

  Line 446 in 49943d5

  value = c.fetchall()

• Convert exceptions from fetchall in dbconnection._queryAllDescription

  sqlobject/sqlobject/dbconnection.py

  Line 463 in 49943d5

  value = c.fetchall()

Activity

1. sigmavirus24

   added

   enhancement

   on Dec 26, 2014
2. phdru

   modified the milestone: 3.0 on Feb 6, 2015
3. phdru

   assigned

   sigmavirus24

   on Feb 19, 2015
4. drnlm commented on Oct 27, 2016

   

   drnlm

   on Oct 27, 2016

   More actions

   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)?
5. phdru commented on Oct 27, 2016

   

   phdru

   on Oct 27, 2016

   Member

   More actions

   Does this need to be fixed?

   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.
6. drnlm commented on Oct 28, 2016

   

   drnlm

   on Oct 28, 2016

   More actions

   "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.
7. phdru commented on Oct 28, 2016

   

   phdru

   on Oct 28, 2016

   Member

   More actions

   The other connectors don't.

   That's exactly the concern of the issue.

Issue actions