[Zope-dev] Re: Refresh trashes acquisition

[Ross Boylan]

On Sat, Jul 27, 2002 at 12:26:04AM +0200, Lennart Regebro wrote:
> 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.
Just to be sure I understand: so if c is persistent, and I say
c.d = a.__of__(b)

and then a few transactions later I come back and get c.d, I am not
going to find it's a.__of__(b)?

And also, does this mean that 
c.d = b.a
also will not work?  Or is it only the __of__ that has the problem?
> 
> > 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? :-)
Just proving the impossibility of coummunication.:)

The intended meaning is this: suppose Zope has invoked the method foo
on the object a.  Then a.b in foo (or, better, the expression self.b)
does acquisition, but if I run off and pull an object c from the
database, c.d will not have acquisition.  Is that what you meant to
say?

> 
> > 3. Acquisition contexts only stay around objects that subclass the
> > relevant Zope classes (Persistence and/or Acquisition).
> 
> This is also correct.
Clearly subclassing from Acquisition and Persistent is a necessary
condition for storing acquisition contexts.  Is it also sufficient?
The statement 1 above seems to imply not, and the earlier statement (by
someone else) that acquisition does not survive transaction boundaries
goes further.  As I understood it, it meant that it is impossible to
store acquisition contexts reliably.

As I understand your final sentence in the next excerpt, you are
saying that it should be possible to store acquisition contexts across
transaction boundaries, but problems with refresh are messing things
up.  So I think there is a disagreement about the theoretical
capabilities of 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.
> [...]
> > 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.
[snip]

> 
> > 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.

In either case, I can't see why a duplicate copy would be created.

I am keeping a separate list for two reasons.  First, I don't trust
ObjectManager to retain the original sequence in which the objects
were entered (since the API docs indicate no such guarantee).  Second,
I don't trust the ObjectManager getItems('type') method to recover
objects that are subclasses of 'type' as well as 'type'.  The actual
code does a fake subclass test (since isinstance doesn't work with
extension classes--aargh) and only puts some items in the persistent
list.