[ZODB-Dev] undo and zodb

[Toby Dickenson]

On Tuesday 03 Sep 2002 2:04 pm, Barry A. Warsaw wrote:
> >>>>> "TD" =3D=3D Toby Dickenson <tdickenson@geminidataloggers.com> wri=
tes:
>
>     TD> No, and that sucks. I am considering extending
>     TD> DirectoryStorage.Full with an automatic background packing
>     TD> process that uses per-object history-level settings. This will
>     TD> be useful in this scenario plus many more.
>
> Do you have an API in mind for that?

no, Ive not thought very deeply.=20

>  I've been hacking on Autopack, a

wooohoo! I wasnt aware of that.

> very simple and minimal Berkeley storage with no undo or versions.  It
> would still store some number of object revisions for a short period
> of time, primarily for performance reasons.

Yes. berkeley.Packless performs all of its magic inside the transaction=20
_finish, which unnecessarily increases transaction commit time. Its bette=
r to=20
perform this housekeeping asynchronously.

>  It has an autopack()
> method, but I'm still teasing out the semantics of that.  The idea
> would be to have a storage-wide setting controlling how far back
> transactions would be kept, although you wouldn't be able to access
> those older transactions through the api.

I see Autopack uses a reference count. That is efficient, but it does mea=
n=20
that one small bug or database corruption can lead to it deleting whole=20
sections of your database. Ive no reason to think that it currently has s=
uch=20
a bug, but I am hoping to aim for a more fault-tolerant solution for=20
DirectoryStorage.

> Of an on, we've talked about per-object controls, but we've never
> gotten very far.

A problem is that the storage layer only gets to deal with pickles, rathe=
r=20
than objects. That makes it hard to set per-object storage-level properti=
es.

An easy option might be to set these controls per-class (rather than=20
per-object). The storage layer can easily extract the class name from the=
=20
pickle. Are there any cases where that is not adequate?