Stefan Franke wrote:

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.

I'll admit that cyclic data structures are pretty rare, so handling them may not be totally correct in every case. Export of objects partcipating in cycles is potentially, uh, confusing, unless the cycles are with objects that are totally contained within the object being exported, although containment is pretty hard to check. I should probably take this error check out.

>> Would also like to hear more about this... > Like what? :)

More or less simple answers like "this is ok and this is not",

OK, but I need to know what "this" is. I don't think you want me to enumerate all possible "this"s. ;)

or "you can store any complex Python data structure inside the DB,

You can store any complex Python data in the DB subject to: - It must be picklable, - It must follow the persistence rules: - Root objects must be "persistent" meaning they subclass BoboPOS.Persistent (or implement an undocumented interface that BoboPOS.Persistent implements, sigh) - Subobjects of persistent objects must be "persistent" or they must be immutable, or be used immutably, as in: def add_member(self, member): members=self.members # Oops, mutated a list members.append(member) # OK, so pretend it's new and readd it self.members=members

but in conjunction with the management interface, you get the following drawbacks.."

Basically, the objects need to implement certain interfaces if they want to play in the management system. If they don't want to play, they have alot of freedom. We need to do a much better job of documenting these interfaces.

I'm still a quite unclear about the object management in the database itself

The object management at the database level tries to be as transparent as possible. The wish is that you don't have to think about it. Basically, if you follow the rules above, you should be OK. Probably the biggest pitfall in the database is the inability to get to database objects when their classes can no longer be imported, because classes or modules have been moved or deleted or because errors have been introducted into the module source. We need to figure out ways to make these problems easier to diagnose.

and the management layer Zope adds. But maybe I just have to read the docs harder ;-)

Maybe you just need to read my mind better. ;) Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.