[ZODB-Dev] Preventing a folder from being packed

[Toby Dickenson]

On Friday 16 May 2003 4:28 am, Shane Hathaway wrote:

> Echoing Sean's point, at ZC we have lately followed a pattern of using
> mounted databases because different parts of the object system have
> different database requirements.  Catalogs, sessions, and Wikis all get
> mounted for different reasons.  Packing characteristics are only one
> dimension.

How do you avoid synchronisation problems across undo when Catalogs are in 
their own storage?

> I agree, though, that you could retain history without too much trouble
> if the work is done during packing.  I wasn't happy with the idea of
> marking whole transactions as permanent, but retaining any object
> reachable from particular roots could be useful.  I'm curious about a
> couple of edge cases: if the user deletes an ExtraHistoryFolder, does it
>   (and its children) ever get packed away?  It seems like it shouldn't,
> since the user may later undo the deletion, but in reality the user may
> have intended for it to vanish for real.

The deletion can only be undone for as long as there is sufficient history of 
the parent folder from which it was deleted.

Once that folder's history has been packed away, all revisions of the 
ExtraHistoryFolder can also be packed away using the reachable-from-root 
rule.

>  And what do you do if an
> ExtraHistoryFolder (with children) gets uncreated? :-)

DirectoryStorage has the same corner case today. A related corner case is what 
to do if different revisions have different class names.

Today I think DirectoryStorage gets this wrong - I think the right rule is to 
use the class name in the most recent revision that contains a class. 
uncreated (george bailey) objects are revisions that do not contain a class.

-- 
Toby Dickenson
http://www.geminidataloggers.com/people/tdickenson