[ZODB-Dev] Object references

Fri, 11 Jan 2002 18:59:56 -0500

Let me try to restate your requirement. You want to
be able to refer to an object and you want to know what 
place the object is in. You don't want to keep track of the place
yourself, you want to be able to ask an object for it's place.

I see a couple of ways to do this.  

1. The object keeps track of it's own place. This approach has
   a couple few shortcomings:

   - It's more work for the object

   - The object can only be in one place, or it has to keep a list
     of places.

   - Lots of circular references get created. While ZODB and Python
     handle circular references OK wrt garbage collection, it's a lot of work.

     Worse, circular references complicate copying.  
     I guess this is where your "weak" references come into play. In this context, 
     a weak reference would not be copied when you copy the refering object.

   I guess I see copying and pasting as the significant issue, not circular 
   references.  You could perhaps invent a container reference and play with the
   Zope copy/paste framework to arrange that when the object was copied, you 
   didn't copy the sub-object. I suppose the are a number of ways this could be
   done, with or without involving ZODB.

2. You could use a third object to keep track of the object reference. 
   For example, if you used a catalog, you could store the catalog id of 
   the object and then get the object from the catalog when you need it.
   This gives you the object in-place. You'd have to arrange that when the
   object got moved, the location stored for it in the catalog was changed 
   without channging the catalog id.

Two is easier with existing software. :)

Jim

Casey Duncan wrote:
> 
> Sorry, I had a biblical email descibing my thought process here that I didn't
> send to spare you all. I attached it though for the purposes of completeness.
> 
> My terminology was also incorrect, circular refs aren't the problem. Actually
> I'm not completely sure I need weak refs. What I am trying to do is make it
> so that an unwrapped object can identify where it is mounted in Zope. So that
> a wrapper can be constructed around the object that would be equivilant to
> the wrapper you would get through acquisition by name (but without needing to
> know the name or mounted location of the object).
> 
> The reason is simple. I want to reference a persistent object that is mounted
> in some arbitrary location in Zope from another persistent object. The
> mounted location of the original object should be able to change without
> breaking the reference.
> 
> However I want to be able to access the referenced object so that it is
> wrapped based on where it is mounted, not relative to the object containing
> the reference.
> 
> Clear as mud? 8^)
> 
> On Friday 11 January 2002 02:53 pm, Jim Fulton allegedly wrote:
> > Casey Duncan wrote:
> > > I've going up oneside and down the other trying to figure out a better
> > > way for Zope objects to robustly refer to one another. I am constantly
> > > battling either Acquisition or Circular references (which the former is
> > > meant to alleviate).
> > >
> > > Acquisition is all swell and quite convenient, but sometimes you need to
> > > store a persistent direct reference to an object. This in and of itself
> > > is easy. The hard part is doing that and having the ability to use the
> > > object in its original containment environment (for lack of better
> > > terminology on my part).
> >
> > What prevents you from using it in it's original containment environment?
> >
> > > In other words you can have the cake (the object), but you can't eat
> > > it too (use it wrapped with its original container).
> >
> > This doesn't actually clarify anything, since I really don't know
> > anything about the cake you want. ;)
> >
> > > I have come to the conclusion that there is not general application level
> > > way to make this work. So, that leads me here. Maybe there is something
> > > that can be done at the database level to help. I have a general
> > > solution, but it creates a large amount of circular references, so I
> > > think that a system level weak reference implementation would be very
> > > helpful.
> >
> > Your problem description is too unclear to offer any help.
> >
> > > I see that there is a PEP (205) to get weak refs directly in Python,
> > > which is encouraging.
> >
> > Python has weak references.
> >
> > > I also saw several other implementations. I was wondering though
> > > how hard it would be for me to implement such a thing leveraging the ZODB
> > > storage cycle as a trigger.
> > >
> > > I figure that in memory, the object references could be the same as
> > > regular references. The application would not know better. However, when
> > > the object was removed from memory, the ZODB would drop references marked
> > > as weak and eliminate those objects no longer referenced. When the object
> > > was reloaded the __setstate__ or what have you would reestablish the
> > > references to those objects that still exist. Any weak references made to
> > > since garbage collected objects would no longer be valid and would raise
> > > an exception when accessed.
> >
> > The ZODB alreadt does something like this. In fact, circular references
> > among persistent objects don't cause memory leaks.
> >
> > > So I guess my questions are:
> > >
> > > Am I right that an application level solution is not practical and if so
> > > what could be done at the DB level to facilitate this?
> >
> > I can't tell what problem you are trying to solve.
> >
> > > Should I shut up and just wait for Python 2.x to support weak references?
> > > If so, will ZODB4 support them?
> >
> > Python already has wek references. In fact, in the Zope3 branch,
> > I'm using them in the ZODB cache, although I think I'll eventually
> > switch to a ZODB-specific approach that uses less memory.
> >
> > Jim
> 
> --
> /---------------------------------------------------\
>   Casey Duncan, Sr. Web Developer
>   National Legal Aid and Defender Association
>   c.duncan@nlada.org
> \---------------------------------------------------/
> 
>   ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                         Name: References.txt
>    References.txt       Type: Plain Text (text/plain)
>                     Encoding: 8bit
>                  Description: My Thought Process

--
Jim Fulton           mailto:jim@zope.com       Python Powered!        
CTO                  (888) 344-4332            http://www.python.org  
Zope Corporation     http://www.zope.com       http://www.zope.org