Jim Fulton wrote: > Sorry you didn't get an answer. There is no problem with creating > acyclic or cyclic graph constructors in the, uh, object hierarchy, > which BTW, need not be a hierarchy. :) Not too long ago I experimented a little with cyclic structures inside Zope's database. One thing I noticed was, that the copy support failed with tracebacks like this: Traceback (innermost last): File D:\Programme\zope\koelnzope\lib\python\ZPublisher\Publish.py, line 877, in publish_module File D:\Programme\zope\koelnzope\lib\python\ZPublisher\Publish.py, line 590, in publish (Info: /BLS/1000/ADV-Angelegenheiten/manage_pasteObjects) File D:\Programme\zope\koelnzope\lib\python\OFS\CopySupport.py, line 176, in manage_pasteObjects (Object: Navigation) File D:\Programme\zope\koelnzope\lib\python\OFS\CopySupport.py, line 361, in _getCopy (Object: Navigation) File D:\Programme\zope\koelnzope\lib\python\BoboPOS\PickleJar.py, line 327, in export_file File D:\Programme\zope\koelnzope\lib\python\BoboPOS\SimpleDB.py, line 958, in exportoid ExportError: Object 184337 references itself This led me to the conclusion to better leave my hands off non-hierarchic data structures which differ from those created by the management interface itself. >> Would also like to hear more about this... > Like what? :) More or less simple answers like "this is ok and this is not", or "you can store any complex Python data structure inside the DB, but in conjunction with the management interface, you get the following drawbacks.." I'm still a quite unclear about the object management in the database itself and the management layer Zope adds. But maybe I just have to read the docs harder ;-) Stefan