[Zope-dev] Re: Refresh trashes acquisition

[Lennart Regebro]

From: "Ross Boylan" <RossBoylan@stanfordalumni.org>
> I don't follow that last paragraph.  Does it mean
> 1. acquisition created by a.__of__(b) doesn't survive transactions.

Correct.

> 2. a.b only does acquisition if a is the active object that is being
> published (or perhaps only if a is a newly instantiated product
> instance).

I dont' understand this sentence. Are you punishing me for being impossible
to understand? :-)

> 3. Acquisition contexts only stay around objects that subclass the
> relevant Zope classes (Persistence and/or Acquisition).

This is also correct.

> If the statement just means that containment only survives for
> subclasses of Zope objects that are stored in ZODB, that's not the
> issue.  The containment relations that got nuked were in ZODB.
[...]
> The q's in lq seemed to retain their original aquisition context
> (i.e., b) until I refreshed.

They should retain this after refresh too.

> P.S. Since I started this thread in zope-dev, and since there seems at
> least some argument it should stay here, I'll continue it here.

Do so. It is strictly speaking off-topic, but I'm covertly trying to make it
into a amailing list for developing *with* zope. :-) There is no such
mailing list, and one is needed. The development *of* Zope can be (and
indeeed largely is) discussed in the zope-coders list.
If you post questions that need guru-attention, then it will drown in
zope@zope.org. And thats not just a bad thing, they high traffic on
zope@zope.org is there because a lot of people is using Zope, which is good!

> The more I think about acquisition, the less I think I understand it.
> My original mental model of was someting like the containment
> hierarchy I've implemented by hand, so that if b is in a b always
> knows that its acquisition context is a.  But the docs actually say
> acquisition context is from the access path,

Yes, so you if you have this tree:
A
  b
C
  d

You can access b through /A/b or /C/Ab or /C/d/A/b and it will acquire the
things in this path.
This is can be used to create neat and magic things, but is easy to f*ck up.
:-)

> doesn't.  On the third hand, my original code was like this:
>   class MyClass(ObjectManager, ...):
>     def _setOb(self, id, obj):
>       ObjectManager._setOb(self, id, obj)
>       self.myPersistentList.append(obj)
> and this did work intermittently, even though obj is not accessed
> through self when added to the PersistentList.
> I also tried the following for the last line:
>       self.myPersistentList.append(self,obj.__of__(self)),
> but it didn't help.

I'm not sure if you this way will get two references to the object or two
copies of it, but you att it both directly to the MyClass instance, and to
its persistent list, which I don't see the point of doing.