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?


"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]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to