Re: [Zope-dev] Alternative Storages: (was RelationalStorage (was LocalFS))
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.
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.
participants (2)
-
Jason Spisak -
Phillip J. Eby