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