Re: non-undoable storage using directorystorage?

On Monday 22 November 2004 10:14, Tim Hicks wrote:

> Ok, so would that involve writing an adjusted version of
> _mark_reachable_objects or perhaps _mark_reachable_objects_impl?  I had a
> look at those methods and... eek!  It all looks rather complicated and I
> couldn't even figure out where the looping over the old revisions actually
> happens.  Got any pointers?

The file whose name is calculated as ('o'+stroid+'.c') contains the current 
serial number of the given oid. serial numbers are also known as "transaction 
id" or "tid".

(Some parts of zodb maintain a subtle distinction between "object serial 
number" and "transaction id". afaik every storage defines them to be the same 
thing, so in practice we can forget that a distinction ever existed.)


The files whose names are calculated as ('o'+stroid+'.'+strtid) contain the 
data for one revision of that oid. That includes the pickle, which is used to 
determine the oids referenced by this object. These end up in the variable 
"allrefoids" - you need to keep this mechanism.

That file also includes the tid of the preceeding revision. The "while 1:" 
loop scans back through history. The "keepclass.expired" method is used to 
determine whether a given tid is sufficiently old that it does not need 
keeping.

> ps Is there a reason why there are two _mark_reachable_objects methods
> declared on Full.Full?

An oversight. Python will have been using the second one. I have now removed 
the first one.

-- 
Toby Dickenson

____________________

Important Notice:

This email and any attachments are confidential and may contain trade secrets or be legally privileged. If you have received this email in error you must not use, rely upon, disclose, copy or distribute the contents. Please reply to the sender so that proper delivery can be arranged and delete the email from your computer.
Gemini Data Loggers monitor incoming and outgoing email to ensure satisfactory customer service, maintain company security and prevent abuse of their email system. However, any views expressed in this email are not necessarily those of Gemini and Gemini cannot be held responsible for the content.
Gemini makes best efforts to ensure emails are virus free; however you are advised to carry out your own checks. Gemini does not accept responsibility for any damage resulting from email viruses.
____________________



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/