[Zope-dev] Alternative Storages: (was RelationalStorage (was LocalFS))

[Jason Spisak]

Phillip J. Eby:

> 
> Basically, what you've described could be considered an instance of the
> Specialist and Rack patterns of the RIPP model, but with a less flexible
> implementation.  That is, you can do what you just described using the
> Specialist/Rack patterns, but what you described won't do everything
> Specialist/Rack can (such as mixed-source data for the same object or a
> sensible place to put class extent methods (e.g. find, listAll, that sort
> of thing)).
>

What about storing the class data itself in a Rack?  Is there any
limitation 
to what you can put into a Rack.  I am only asking this to clarify what we
are heading towards.  Somewhere to put just the instance data.
 
> 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  > 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.)

So a "standard" ZODB connection from which a class can get it's data which
can be fulfilled by anything inherited from BaseStorage?

> 
> 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.  

Is that for acquisition sake or class container sake or what exactly?

>I'm
> assuming each provider may be shared by more than one Rack or rack-like
> object,

I agree.

> 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.)
> 

I've gone over you ppt presentation 3 times to try to soak it up, so
forgive me if I am missing a few things.

All my best,

Jason Spisak
CIO
HireTechs.com
6151 West Century Boulevard
Suite 900
Los Angeles, CA 90045
P. 310.665.3444
F. 310.665.3544

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.