"Phillip J. Eby" wrote:
At 05:42 PM 5/11/01 -0400, Shane Hathaway wrote:
"Phillip J. Eby" wrote:
I'm not quite clear on how exactly you suggest mapping from RDMBS -> ZODB. There's a *significant* (IMHO) impedance mismatch between ZODB's arbitrarily identified variably structured single records and SQL's content-identified fixed-structure record sets. This is what application frameworks/toolkits (such as your own DBAPI product) are needed for.
If you implement this at the Storage level, yes, there is a major mismatch. But at the Connection level it makes a lot of sense. Connection basically exposes a pile of pickles as objects; an OR mapping exposes a complex schema as objects.
I think that understanding will change the rest of your response. :-)
Nope. As far as I can see, all that does is leverage ZODB Connections as a crude sort of Rack that only provides a mapping-like interface for retrieving objects, without helping any of the higher-order needs of an application. I guess if you define O-R mapping as "can you store and retrieve an object's properties from a database", then I guess you've succeeded at that point. But if that was all my O-R apps needed, there would've been no reason to use the RDBMS; I could've just used ZODB and a BTree with less bother.
I'm telling you there's a lot more you can do with the code that makes up ZODB. The mapping interface is not the key to the way Connection does its work. OIDs don't have to be strings. If we just use cPersistent, cPickleCache (which is misnamed), and Transaction to implement an OR mapping, here's what we get for free: - A transparent, transactional database. - Potential interoperability with everything written for ZODB. - Robust, tested code. - Optimizations in C. Since you challenged me :-) I decided to put together a prototype. What I came up with was a database connection that sets a different _p_jar for each persistent object. The _p_jar is an object that manages the storage for only one persistent object, making it possible to customize the storage. There was only one hurdle in this approach but I hacked around it: the tpc_* messages get sent to each _p_jar. Then I wrote a very minimal test that doesn't connect to an RDBMS but stores and retrieves simple objects in a dictionary. OIDs are still necessary to support multithreaded invalidation messages. But the OIDs in the prototype are a tuple consisting of a schema ID and a record ID. That way the record IDs only need to be unique within an RDBMS table (or combination of tables.) I didn't think anything like this was possible before I got to know Jim. I still didn't understand when he presented the idea months ago. But now I see the idea really is workable. The advantage is that it lets us completely isolate RDBMS storage details from the application. The next thing to do is to write a fishbowl proposal. Shane