[Zope3-dev] Using a RDBMS with Zope3 (was: Re: Zope X3 3.0.0 alpha 1 released)

[Sidnei da Silva]

On Thu, May 20, 2004 at 09:55:57AM -0400, Derrick 'dman' Hudson wrote:
| Sidnei,
| 
| On Thu, May 20, 2004 at 10:35:12AM -0300, Sidnei da Silva wrote:
| 
| | ... And you can still use something else if you dont like it. We, for
| | a fact, used just the connectors and the transaction
| | registration. Everything else is handled by SQLObject. Meaning near
| | *zero* custom SQL written.
| 
| Could you provide an example showing how you organized this?  I want
| to do the same thing on a project.  I've looked at SQLObject and
| understand how to use it with the connection string hard-coded in a
| module.  I haven't yet tried to figure out how Z3 handles RDBMS
| connections.  I would really like some pointers on the "right way" :-)
| to approach this.

I will do a very rough description of how it works. If after that you
still want to look at the code, then we can chat in pvt :)

Basically, I wrote an adapter that wraps a rdb connection from zope
into a sqlobject connection object. I keep one of those adapters per
thread on a global module cache to reuse the connections and keep them
always open.

However, before Ian implemented the 'lazy updates' feature, each
change on an object was immediately reflected into the rdbms, so it
was pretty hard to control transactions, even with auto-commit
disabled.

Then, with lazy updates, every time an SQLObject is modified, a
private '_dirty' attribute is set on the instance. The new values are
cached and just sent to the rdbms when you call 'sync()' on the
SQLObject instance. I used this artifact to 'mirror' the behavior of
zodb's 'Persistent' class by creating a SQLTransactionManager where
objects are registered when '_dirty' is assigned a non-false value.

The SQLTransactionManager is then registered with the current
transaction. Bingo! When zope does a transaction.commit(),
SQLTransactionManager is notified and goes calling '.sync()' on each
SQLObject instance that got modified during the transaction.

The difficult part is having to assign the connection adapter to
SQLObject Class's __connection__ attribute, but for that I added a
'getFactory' class which checks if the connection is from the current
thread, and if not, replaces it. This is the part that would benefit
from some cleaning.

I hope that helps.

-- 
Sidnei da Silva <sidnei at awkly.org>
http://awkly.org - dreamcatching :: making your dreams come true
http://plone.org/about/team#dreamcatcher

FACILITY REJECTED 100044200000;