[Zope-dev] Racks and Persistence (was Alternative Storages)

[Phillip J. Eby]

At 01:03 AM 5/4/00 +0000, Jason Spisak wrote:
>
>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.

Racks hold a collection of objects derived from the RackMountable base
class.  The objects may be ZClass instances, or instances of a Python
ZClass base, as long as in either case they derive from RackMountable.
RackMountable (as of ZPatterns 0.3.0) contains a C mixin class that gives
Persistent objects the ability to coexist with (renamed)
__get/set/delattr__ methods.  It also contains hooks that delegate various
operations to the Rack, such as propertysheet management.

When a RackMountable is retrieved from a Rack, the Rack calls _setRack() on
the RackMountable to tell it where it came from.  From then on, the
RackMountable can delegate its data management operations to the Rack.

Conceptually, a Rack is like a database table.  It holds only one kind of
object (although there are ways around that if it's really needed), and has
a key by which items are stored/retrieved.  The basic Rack interface
consists of Rack.getItem(key) and Rack.newItem(key).  Both return an
instance of the class the Rack stores.  You then talk to that object
directly for any operations you need, such as setting its initial
properties, or telling it to delete itself from the Rack.  Racks have a
"Methods" tab, however, where you can add your own DTML, Python, or
whatever else to add extended operations such as searching, automatic
generation of sequential ID's, etc.  By default, Racks use the "id"
attribute as a key, but this can be overridden in a subclass if you desire.


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

Um, no, it would need to be something which could provide a ZODB
connection.  The connection would be back-ended to something inheriting
from BaseStorage, yes.  In practice, all that Racks need is someplace to
retrieve a BTree object with all its attached children (PersistentMapping
objects containing instance data and/or propertysheets).


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

It's a ZODB internal issue.  A ZODB has to have a root object, which is
normally a PersistentMapping.  Items placed in that root are never garbage
collected.  That root's namespace would have to be shared among the users
of that ZODB in some fashion, and garbage collection would be important so
that deleting a Rack from the primary ZODB would ensure deletion of its
data from the secondary ZODB.  Or, alternatively, the secondary ZODB must
expose access to the root object to manually remove sub-roots.