DCOracle2: More Development

Further to my previous entry about DCOracle2 it transpires that there are a few more issues which need resolution, in addition to the strange insert error message:

• the client will be using Oracle DataGuard to ensure a replicated standby of their database is available. In the event of a fail-over the Zope-to-Oracle connection will be severed and runtime errors will ensue. There are two obvious ways to fix this:

  • use a standard_error_handler:

    add something to the Zope instance which reconnects the database connection and reloads the current page, but this could be messy in a number of ways.

  • patch DCOracle2:

    perhaps the logical place to put the reconnection code as it is a function of Oracle's client libraries and one's tnsnames.ora configuration that this fail-over can be made to happen seamlessly.

• looking at db.py it seems as though it was possible to the results of two queries appended to each other by separating the two queries with a NUL byte (ASCII 0), but when I tried this I found that both queries had to present the same schema (in which case there is no advantage over an SQL union) and I still received runtime errors when they did have the same schema.

• arbitrary limit of 9999999 rows will be fetched.

• various globals in db.py are definitely not good for concurrency, and so they've been hacked out.

The result is DCOracle2 v1.3i, available as source tarball and patch to be applied to v1.3b patched to v1.3f.