[Zope3-dev] RDB support

[Phillip J. Eby]

At 10:15 AM 4/11/02 -0500, Stephan Richter wrote:

>>I've done a significant amount of work (measured in man-months) on the 
>>above two notions in TransWarp.  I don't know how applicable the 
>>implementation is to the Zope 3 core or what other people will want, but 
>>what I *have* tackled is:
>>
>>* Uniform read/write API for "records" stored in LDAP, relational, or 
>>other data sources
>
>I wanna see that! This would be an incredible leap for us! Can you send me 
>a link?

HTML docs at:  http://telecommunity.com/TW/doc/src/TW/Database/

CVS view at:  http://cvs.eby-sarna.com/TransWarp/src/TW/Database/

Project homepage: http://telecommunity.com/TransWarp/

A short example using the LDAPModel module...  Note: ignore the 
"MyConnections.py" and "MyLDAP.py" files - they were Ulrich's patches to 
fix bugs in an earlier version of the package.  The much shorter files 
"MyDataLayer.py" and "test.py" are the actual example:

   http://www.eby-sarna.com/pipermail/transwarp/2002-March/000072.html


>>If anybody's interested, check out the TW.Database package from TransWarp 
>>CVS.  The "Connections" module is of little relevance to this, and the 
>>"Interfaces" module is lagging behind the implementation at the moment, 
>>but the "DataModel" and "LDAPModel" modules should provide interesting reading.
>
>Could you send us a link?

See above.


>>The implementation is at present alpha quality, but there is extensive 
>>design backed by lessons learned from ZPatterns and relational DB 
>>applications built atop ZPublisher.
>
>Would you be willing to sign a Zope Contributor Agreement and integrate 
>your code in Zope? All that sounds really cool.

I'd probably be willing, although I haven't read the agreement at this 
point in time.  I expect, however, that my implementation will be somewhat 
controversial for incorporating into Zope proper.  It relies upon TransWarp 
features such as the Service-Element-Feature framework, "component 
bindings", "once attributes", and so on, which are not part of the Zope 
Component Architecture, and I doubt Zope Corp. will want to add so much of 
TransWarp into Zope just to get the database caching tools, any more than 
they'd want to incorporate Twisted Python just to get the web server.  :)

But, the bulk of my implementation could be ported so as not to use those 
features.  And I imagine that if my interfaces were cleaned up a bit, then 
the TW and Zope core implementations of the protocols would at least be 
interoperable.


>I like that. This means your code deals only with low-level communication. 
>ORMapping is something for higher levels.

Here's how I see the layers:

Application Domain objects (ignorant of storage mechanism)
Application Dispatch objects (mapping from domain to data layer)
Application Data layer - manages caching, transactions, record types, and 
retrieval
Implementation Layer - actual SQL queries or other DB interaction code

The most useful stuff I have at the moment relative to Zope 3 is the third 
layer: caching, transactions, record types, and keyed retrieval.  I have 
some fourth-layer code for LDAP, but nothing for SQL as yet.  The 
third-layer code is intended to be subclassed to add fourth-layer code.


>I am really looking forward to seeing your code. It would be fantastic, if 
>you could join the Zope 3 development team!

Have a look and let me know what you think, or what questions you 
have.  Unfortunately, I will be out of town from tomorrow (the 12th) until 
next Friday (the 19th) and will not have access to email until I return.