[Zope-dev] Re: Refresh trashes acquisition

[Adrian Hungate]

> 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)?

What you will find is that you are leaking acquisition wrappers at the speed
of light. (You will _probably_ find the data you want, as well).

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

Don't store acquisiton contexts. This is badness. I still don't understand
why you would want to... If all you need is an ordered ObjectManager, I
believe I recall one, called OrderedObjectManager (Or something like that).
If not, they are very easy to simulate - Don't give the user access to set
the ID of the object, auto generate them as sequence numbers (For example -
Q010, Q020... etc)

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

Acquisiton should really be considered an ephemeral thing, caused BY
observation, like a rainbow. Don't try to store it, but if you set up the
correct conditions, it will be there when you expect it.

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

Read up on pickling and shelves - ZODB is based on that (Although it is much
more complex and advanced).

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

If you don't like what getItems does, override it in your subclass...

Adrian...