Phillip, Just a quick comment: I re-read this posting today (more than a month old) and realized that, according to my understanding, mounted databases fulfill your requirement for an alternative persistent provider. Am I correct? Shane "Phillip J. Eby" wrote:
The only thing missing from Rack today that would be needed to implement a "ZODB per class" approach, is the ability to use an alternative "persistence provider" for storage. I'd like to see some discussion on a mechanism for providing such things. My thought is that they would sort of look like SQL Connection objects: something you can add, that can be acquired, and which Racks can select from a dropdown. (The dropdown even already exists in the about-to-be-released ZPatterns 0.3.0, it just is empty except for an option to use the primary ZODB.)
The thing about these "persistence providers", though, is that they need to provide some kind of root for each thing that wants to use them. I'm assuming each provider may be shared by more than one Rack or rack-like object, that security constraints need to exist on who can create root branches in these DB's, and that the branches need to be able to be removed when their owners go away. If there were a design (or implementation, better yet) for gizmos like these, hooking up Racks to use them would be a snap, since all Racks need to do is store a single BTree.
(By the way, Racks can be written to store the "base" object data in an RDBMS, db file, LDAP, or anything else that you can implment createItem(), retrieveItem(), and deleteItem() methods for.)