[Zope3-dev] RDB support

[Casey Duncan]

Lalo Martins wrote:
> On Wed, Apr 10, 2002 at 12:03:22PM -0600, Casey Duncan wrote:
> 
>>Even better I think we might start to think about ORMappings and make 
>>recordsets just a simplistic implementation of them. So, we should 
>>probably abstract this from a basic interface for mapping objects to 
>>records.
>>
> 
> ORMapping!

I left the exclamation mark off mine, since I don't want to get 
anybody's hopes up. ORMappings means different things to different 
people. But I think we should at least aim in that direction for a start.

> What I would like to see is some URL that renders *one* "row" of a query
> result, ORMapped and skinned via the normal skin machinery.

I would image that once a record/recordset is a full fledged object, 
creating views for it would be little different from anything else. 
Actually, given the component architecture's adapters, it wouldn't even 
need to be a very sophisticated object in and of itself.

> Then what I would really love would be to make "sql mappers" traversable.
> But I know, that would be a bit harder.

I think it is along the same lines. Zope 2 makes an attempt at this with 
its direct ZSQL traversal scheme.

> I think this abstracts in a "external data mapping" interface, along with
> diverse stuff like FS access, IMAP, LDAP and the works. (Zope2 LDAP adapter
> is the way I think all adapters should be.)

It would certainly be nice if the application could be better/fully 
abstracted from the data store. That would allow truely storage 
pluggable applications/products.

> This makes Zope3 more object-oriented and consistent - mixing and matching
> different paradigmas makes for a worse learning curve and user experience.

Agreed. However, as Stuart pointed out, the current model has advantages 
and is ultimately more flexible (and also probably better performing 
given a good design) than any general ORMapping could be. So there is 
probably a place for both low level and high level database abstraction 
in the system. A key part of this architecture will be balancing these 
different requirements.

-Casey