[Zope] Persistent references to persistent objects ?!?!

[Jean-Francois.Doyon at CCRS.NRCan.gc.ca]

Dieter,

Hmmm interesting point.  I suppose a basic rule of thumb would be that the
reference should never be stored directly as an attribute of a folderish
type ?

I can imagine many useful scenarios where keeping references to objects can
be very handy (Versioning, workflow, lists of objects, etc ...) ... Although
I have to admit the symlink think had never really even occured to me.  I'd
imagine instead maintaining a list of references for instance, maybe stored
as an attribute of some other non-folderish type ... you know maybe build
some content-type class that, as part of it's functionality, keeps
references to objects ?  This should make it safe from any unexpected
behavior like the one you describe, right ?

Thanks for the insight ...

J.F.

-----Original Message-----
From: Dieter Maurer [mailto:dieter at handshake.de]
Sent: Friday, February 06, 2004 3:57 PM
To: Jean-Francois.Doyon at CCRS.NRCan.gc.ca
Cc: zope at zope.org
Subject: Re: [Zope] Persistent references to persistent objects ?!?!


Jean-Francois.Doyon at CCRS.NRCan.gc.ca wrote at 2004-2-5 16:38 -0500:
>I was toying with a few ideas, and discovered that I can actually store in
a
>persistent manner references to other persistent objects !!
> ...
>This is nice because it allows to point to an object without using paths
and
>traversal (So it's quick and dirty), and the reference is maintained
through
>a rename.
>
>I can see some problems related to security, such as if traversal is not
>used, then some security can be by-passed ...

Effectively, the same object resides then at different places
in the Zope hierarchy. This can be very confusing:

  We used Shane's "symlink" product that has similar properties.

  A colleague was able to delete the complete ZCatalog content
  by deleting an object containing a symlink. 
  The deletion caused a recursive "manage_beforeDelete" which
  followed the symlink and unindexed all objects referenced from
  the link target.

  Similar things may happen with your "multi-place" objects
  (especially, "catalog"s and "acquisition" may work inconsistently,
  depending how you access your objects).

-- 
Dieter