[ZODB-Dev] undo and zodb

[Toby Dickenson]

On Tuesday 03 Sep 2002 4:03 pm, Jim Fulton wrote:

> > An earlier phase of the store process has already determined which oi=
ds
> > are referenced by every stored object. It is a shame that this
> > information cant easily be passed down to the storage.
>
> It could be, in ZODB 4. Note, however, that it's pretty easy for the
> storage to get the references. To pass the references to the storage wo=
uld
> require a larger payload. It's possible that the cost of sending more d=
ata
> and the benefit of not having to get the references in the storage coul=
d be
> a wash.

Good guess. I have an implementation of these checks in DirectoryStorage =
in=20
the reference-check-branch, and the performancs costs of using references=
f on=20
every store are indeed negligible.

> >>There could
> >>even be a special error type that would allow the database to recover=
 the
> >>lost object.
> >
> > That recovery couldnt be 100% reliable because the lost object may ha=
ve
> > been turned into a ghost by the cache.

Any objections to adding a definition of a DanglingReferenceError to the=20
POSException module?



On Tuesday 03 Sep 2002 3:33 pm, Jim Fulton wrote:
> Toby Dickenson wrote:
> > On Tuesday 03 Sep 2002 2:10 pm, Barry A. Warsaw wrote:
> >>Autopack.py should solve this problem.
> >
> > By ensuring that it doesnt remove unreferenced objects until they hav=
e
> > been unreferenced for a fixed length of time?
>
> Right. This is less a solution than a mitigation.
> It *is* possible to solve (well, maybe further mitigate) the problem,
> as I sketched out elsewhere.

I think it is useful to implement both approaches. The explicit reference=
=20
checks mean we raise an exception rather than committing a dangling=20
reference. The extra delay on packing means that these weird transactions=
 can=20
commit normally (no exceptions, no dangling references, indeed no sign of=
 any=20
problem)