Hi All, I'm creating an "infinite-set" type product which generates objects on-the-fly based on their URL. In general many more objects are possible than are reasonable to store, yet relatively few would be used at any one time. Hence, a sensible approach is to provide a cache of recently requested objects and serve from the cache whenever feasible. After several design iterations, and one (mostly) working model, which unfortunately didn't scale too well, I've decided on actually inheriting from "ObjectManager" and storing the objects in the main object. As objects expire from the cache, they are deleted. However, with the way Zope's database works, I have to wonder if I'm actually acheiving anything -- the deleted files are still taking up space until the database is packed! So, I'm wondering if (via Zope's API, as this is a Python-based product), there's a way to mark an object as not undoable -- i.e. when it gets deleted, it's really gone. The alternative would seem to be to pack the whole database frequently. Which is what I'll do if there's no other way. It appears that I can get the desired behavior by overloading the _getOb() method of ObjectManager and catching the case of a request for a non-existent object -- if it happens, I just call the code to make the object, add it with _setObject() and then let _getOb() continue with the request, which should now succeed. I presume this would make the cached object visible to Zope calls in all the usual ways (e.g. URL: "parent/cached_obj", Python: "parent.cached_obj", etc). My previous implementation used __getattr__() directly and only worked for the URL approach. Any comments or ideas appreciated, thanks! Terry -- ------------------------------------------------------ Terry Hancock hancock@anansispaceworks.com Anansi Spaceworks http://www.anansispaceworks.com P.O. Box 60583 Pasadena, CA 91116-6583 ------------------------------------------------------