Matt Hahnfeld wrote at 2006-3-13 14:33 -0500:
I found your code a while back and actually looked it over quit a bit
before I started coding the solution I attached. Would you be able to
explain how it works?
It works through a special HistoryJar (for some unknown reason,
the ZODB uses jar as a term for a ZODB connection).
When you create a HistoryJar, you pass in a serial (a timestamp).
Objects retrieved via this connection have (all) the state
as it was current at the time identified by the serial.
The implementation uses the ZODB history for an object
which is the sequence of the object's states corresponding to the
various object modifications. The state with the smallest serial
not smaller than the HistoryJars serial is retrieved by
the HistoryJar (if any).
Most of the implementation is just doing the above operations
in an efficient way.
BTW, if your posted solution is still viable, I'd be more than happy to
help port it to 2.8, or help out in whatever other capacity I can.
I had to override a few (I think a single) Connection methods;
with Zope 2.8 (and upward) almost surely some more/other methods
need overriding (as connections and transaction handling
have changed quite some bit).
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org