[Zope-dev] ObjectManagers and their children

[Michel Pelletier]

Ty Sarna wrote:
 
> In article <3826F005.7429DD42@digicool.com>,
> Michel Pelletier  <michel@digicool.com> wrote:
> > Consists of two file, BTreeObjectManager.py and BTreeFolder.py.  Both go
> > in OFS (but it would probably be smart to make a seperate Product).
> 
> BTW, I wrote something like this a month back or so called ZRack, which
> is similar.  It was based onm BTree at first, but I later changed it to
> use Phillip Eby's simpletree, which has better write performance
> (doesn't always have to update one page per level of the tree). It also
> will assign id's for you, if you want.

BTW, we plan of fixing the update-one-per-level bug, which Phillip
pointed out to us.  Can't make any promises on time...
 
> At any rate, one problem I ran into is that the ZClass support doesn't
> interract well with objectmanager's that don't support __getattr__.
> Adding a ZClass instance wants to add the instance, and then immediately
> getattr it back out.

Hmm.. this sounds like more of a bug in ZClasses to me than OMs, but I
see your point below, it's really about wanting to override __getattr__
 
> It was easy to hack around this, but it sure would be nice if the
> tree-ObjectManager *could* support getattr. The inability to override
> __getattr_ on Persistent subclasses keeps biting me (and others, from
> what I see on the lists) again and again. It would be *really* nice if
> this could be fixed. I'd even be happy with something like "You can't
> override __getattr_, but if you define __foo_getattr__, persistent will
> try it before returning AttributeError".

I suspect jim would frown on another hook, we're trying to avoid as many
new hooks as possible, especialy ones that may have a per hit or per
traversal penalty.  Perhaps I haven't thought about your idea enough
though.

-Michel