[Zope3-dev] RDB support

[Stephan Richter]

>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?

>* Retrieval and cache lookup by single or multi-field unique keys

Nice.

>* Cache consistency/coherency management so that any retrieval always 
>results in the same record object, so long as the record is in cache (and 
>it stays in cache at least as long as anything holds a live reference to 
>it).  Note that this management is required to prevent the possibility of 
>"lost updates" internal to an application which buries the record 
>retrieval in its lower implementation layers.

Yep.

>* Handling of inheritance between record types (e.g. for LDAP object types 
>and relational inheritance patterns) - specifically, the system ensures 
>that regardless of what record type you look something up under, you still 
>get the same underlying record object which "knows" its most-specific-types.

Cool.

>* Update queueing and flushing to minimize unnecessary single-field 
>updates to the underlying database.
>
>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?

>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.

>The model does not address application-level OR mapping; indeed it doesn't 
>even address concepts like associations.  It is strictly a "flat record" 
>management layer, upon which higher-order systems can build.  Actually, it 
>doesn't really have a notion of a recordset per se.  Recordsets are just 
>sequences of records, where each record is sync'd with the cache manager 
>for that record type in order to ensure that no matter the query a record 
>is returned in (within a given thread/transaction), it's the same record 
>object.  Thus, any writes made to it in the current transaction will show 
>through to any other reference to that record which is being held by 
>another application object.

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

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

Regards,
Stephan

--
Stephan Richter
CBU - Physics and Chemistry Student
Web2k - Web Design/Development & Technical Project Management