Persistent references to persistent objects ?!?!
G'day, I was toying with a few ideas, and discovered that I can actually store in a persistent manner references to other persistent objects !! I for instance have a persistent object that has, as an attribute, a reference to another persistent object (Done using Python's standard shallow copying: self.attribute = object). I use this in a scenario much like DB connections/ZSQL Methods, where the ZSQL MEthod would have a stored persistent reference to it's connection object. 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 ... In my few years of using Zope I've never heard of any one using this ... Has anybody ? What are the official pro's and con's ? Thanks, Jean-François Doyon Internet Service Development and Systems Support / Développement des services et soutien de systèmes Internet GeoAccess Division / Division GéoAccès Canada Center for Remote Sensing / Centre canadien de télédétection Natural Resources Canada / Ressources naturelles Canada http://atlas.gc.ca Phone: (613) 992-4902 Fax: (613) 947-2410
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
participants (2)
-
Dieter Maurer -
Jean-Francois.Doyon@CCRS.NRCan.gc.ca