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.) _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
