[SQLObject] DB Backend Version Compatibility
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Ian B. <ia...@co...> - 2004-01-20 20:28:50
|
-------- Original Message -------- Subject: DB Backend Version Compatibility Date: Tue, 20 Jan 2004 15:10:59 -0500 From: Brad Bollenbach <br...@bb...> To: ia...@co... [Here's an email I tried sending to the list, but apparently got spam-filtered.] Hi all, I'm trying to fix a bug in SQLObject right now whereby if psycopg raises an IntegrityError, SQLObject doesn't properly reset the connection (with a rollback() on the connection), leaving it in, effectively an unpredictable state, leading to "no results to fetch" problems when I try to access SQLObjects after that exception occurs. So (obviously) I need to write a unit test that illustrates the problem, and then make the code modifications to make the test pass. There's a problem though: there are errors occurring in the tests. The problem is quite a bit deeper though. When I run the tests with: python test.py -dpostgres --database=sqlo_test I get lots of errors like: ProgrammingError: ERROR: parser: parse error at or near "CASCADE" DROP TABLE so_validation CASCADE (btw, I changed the PostgresConnection in SQLObjectTest.py to point to a special db I created manually, but no matter...) These errors are the result of SQL being run that expects me to be using a PostgreSQL database version >= 7.3. We're currently using 7.2.1 for many, many projects. The problem is that the SQLObject project has no clearly defined requirements for which database versions are supported for each of the backends. The "Requirements" section of the documentation (http://sqlobject.org/docs/SQLObject.html#requirements) must state which versions of databases are required for each of the given backends to function properly. The required version of each database backend should be the earliest version of the backend for which the unit tests pass. Optionally, we could add in little hacks here and there where a known version incompatibility (e.g. the fact that PostgreSQL < 7.3 doesn't support CASCADE on dropping tables) is resolved by detecting the version and using alternative SQL to achieve the same effect (e.g. a manual drop table + drop sequence for PostgreSQL < 7.3, or whatever the most accurate "manual" SQL equivalent is.) If everyone's okay with this I can update the Requirements section with the backend versions that are expected to be supported when I hear from the people who wrote them. Thoughts? -- Brad Bollenbach BBnet.ca |