RE: [Zope] Persistent references to persistent objects ?!?!
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@handshake.de] Sent: Friday, February 06, 2004 3:57 PM To: Jean-Francois.Doyon@CCRS.NRCan.gc.ca Cc: zope@zope.org Subject: Re: [Zope] Persistent references to persistent objects ?!?! Jean-Francois.Doyon@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
On Fri, Feb 06, 2004 at 04:55:26PM -0500, Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote:
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 ?
mxmRelationsManager might help with this. I'm using it for a similar purpose - maintaining paths of related objects that are preserved even if the objects move. It requires adding a line of code to your class's manage_beforeDelete and manage_afterAdd so that the paths get updated properly. i haven't yet checked what happens if i restore a deleted object using "Undo". /me goes to add that to his functional tests -- Paul Winkler http://www.slinkp.com
Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote at 2004-2-6 16:55 -0500:
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 ?
I do not think so. You must be prepared that objects retrieved via persistent references maintained by yourself behave differently than those maintained by the "standard" references. Watch out for any situation where the acquisition context is relevant: e.g. indexing, security, locating of central resources (like "MailHost"), ... Taking enough care, you will probably be able to cope with the situation. Your type of usage may be affected by Zope 3. Zope 3 has abandonned acquisition (called "context wrapper"s in Zope 3 terms) (personally, I am sad about this; "acquisition" has been one of my major selling points for Zope). In Zope 3, objects contain a reference to their parent in the hierarchy. This means that objects know their place in the hierarchy which may make it easier to have references to them in various places. -- Dieter
participants (3)
-
Dieter Maurer -
Jean-Francois.Doyon＠CCRS.NRCan.gc.ca -
Paul Winkler