From: Ian Bicking <ianb@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 <bradb@...>
[Here's an email I tried sending to the list, but apparently got
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
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
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.