[ZODB-Dev] Preliminary notes from fixing a bad data.fs

[Tim Peters]

[Toby Dickenson]
>> That would cause packing to remove all objects that are only reachable
>> via that corrupt object. That might be what you want in this case, but
>> in the general case that would be a dangerous behaviour. Many of those
>> objects might be valuable.

[ethan fremen]
> If you can't unpickle the object, how do you know what objects it can
> reach?
>
> I don't know of any way, aside from visual inspection of whatever binary
> data can be recovered.

That, combined your semantic knowledge of your application and your data.
For example, you may know that all instances of class CalcSummary merely
cache the results of some long-winded computation that can be reproduced if
necessary, so that no permanent damage is done if all CalcSummary objects
are thrown away.  Or you may find that a Rolodex instance can't be unpickled
because it's corrupt, but you can still read the "business phone number"
field from the pickle by eyeball, and use that to look up and repair the
earlier "name" field that got corrupted, and from there go on to repair a
corrupt pointer to a BusinessAssociates container.  Like that.  There's no
end to what a database creator can deduce that no program can even approach.