[Zope-dev] Re: Refresh trashes acquisition

[Ross Boylan]

On Fri, Jul 26, 2002 at 09:34:28AM +0200, Lennart Regebro wrote:
> From: "Ross Boylan" <RossBoylan@stanfordalumni.org>
> > Previously in this thread I was advised that acquisition relationships
> > don't persist across transaction boundaries, and this was consistent
> > with the failures I was getting when trying to use it
> 
> Sure, so you shouldn't create your own acquisition containment and expect it
> to survive over transactions. But the acquisition created by you creating
> Zope objects in the ZODB via the ZMI (or doing the same programatically)
> does of course survive transactions.
> 

I don't follow that last paragraph.  Does it mean
1. acquisition created by a.__of__(b) doesn't survive transactions.
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).
3. Acquisition contexts only stay around objects that subclass the
relevant Zope classes (Persistence and/or Acquisition).

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.

Some of the objects involved were created using product add; all of
them subclassed the relevant Zope classes (hmm, unless it matters that
PersistentList doesn't have acquisition).

To recap the actual relations, where indentation indicates containment:
b   Ballot
 n  NumberStyle
 sq   Suborder of questions
  lq    PersistentList
   q       Question
 q   Question (same ones as in lq above)
  sr  Suborder of responses
   lr PersistentList
    r    response
  r  Response (same as in lr above)

For simplicity, I show only a single question and response; there are
many.

Now, in this story b and q are full-fledged products, created using
the regular add product procedure of ZMI.  b and q programmatically
create the other objects.  n, sq, and sr all get added to their
containers with _setObject, and they are subclasses of Item.  All
classes inherit from Persistent, and all but PersistentList inherit
from Acquisition.Implicit.

I get a q from lq (i.e., not the original context it was created
in) and then try to do acquisition from that q's sr back up to b (n is
the thing I'm trying to get).

The q's in lq seemed to retain their original aquisition context
(i.e., b) until I refreshed.  I then tried setting it explicitly with
__of__, but this didn't work either.


The stuff below points to a simpler theory, one which is definitely
consistent with my experience:

> > (actually, the relations only got zapped when I did a product refresh,
> 
> The refresh in Zope 2.5.1 is unusable, but I haven't figured out why yet,
> and nobody seems to be able to tell me. I don't have the problem that
> acquisition stops working. However, each time I do a refresh, some globals
> disappear, like referenses to other modules and stuff.


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.  Those
with a fine eye for detail might note that I have posted a question
to zope, not zope-dev, in the past couple of weeks, so I am trying to
use the lists appropriately.

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, so a.b has it but b
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.