[Zope-dev] ObjectManagers and their children
Michel Pelletier
michel@digicool.com
Thu, 11 Nov 1999 16:21:35 -0500
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