Nikko Wolf wrote at 2005-6-21 16:13 -0600: > ... >But that begs the questions > + why didn't the stack backtrace give the problem ID?
It would not have helped: the problem was not an individual instance but a class problem... Your problem is of a rather rare type (few people remove "Persistence" from the inheritance chain for persistent objects). In general (not in your special case), the id cannot be determined in case of loading problems. More importantly: The error was detected in ZODB, a component used by Zope but also externally. And ZODB cannot expect all its persistent objects to have an id (indeed most, even in Zope, do not!). > + if "0x28b5" can be deciphered as an ID, how? Neither this nor your original message tells us what the "0x28b5" should be ;-) It probably is the object's "oid" (object id), in hexadecimal form. It is useful, to load the object from ZODB in an interactive Python interpreter to analyse the problem more easily (i.e. use "pdb.pm" to analyse all objects relevant for the exception). > + why didn't the Find locate the broken instance? (it *might* > be since I've created about 15 different portal_types, and > the "ABCD Content" wasn't really what the offending ID was). Because, it would have died (same exception as reported in your original message) when it had tried to access the object. Do not expect to get realiable results when you did something that prevents objects to be loaded from ZODB ;-) > + is this a common problem with file-system (or ZClass) products? Few people remove "Persistence" from the inheritance chain of a class once they have stored persistent objects of this class in the ZODB... -- Dieter _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )