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.