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 "" 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...

Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to