Jim Fulton wrote:

It's a shame ZODB doesn't turn POSKeyErrors into proper Broken objects
as it does when the class can no longer be imported. The problem with
POSKeyErrors is that they prevent you accessing *any object that refers
to the broken object* not just the missing object itself. This means
that when objects *do* go missing, the data loss can be much much worse
than it needs to be.

What does everyone else think?

I think you are right and this should be treated as a bug.

Okay, so I count two issues:

- packing and multiple mounted storages
- POSKeyErrors resulting in failure to load referring object rather than creation of a broken referred object

Where would you like me to file these bug reports?

I'm not sure the situation is as bad as you're suggesting, since I
vaguely recall that inter-object references encode the class of the
referenced object, allowing a parent to load even if its child is gone.

I'm not sure if this is the case for cross-database references. I don't remember the details. Even if it isn't, we should probably create a broken object rather than giving a POSKeyError.

That would certainly aid minimising data loss create by the first and any other POSKeyError-causing bugs ;-)



Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to