Chris McDonough wrote at 2005-10-8 10:35 -0400:
>On Oct 8, 2005, at 6:08 AM, Dieter Maurer wrote:
>> Chris McDonough wrote at 2005-10-5 09:58 -0400:
>>> ...  savepoint difficulty ...
>>> Sure.  BlobStorage is a wrapper around an existing storage.  The
>>> wrapped storage's connections might support savepoints, which implies
>>> that they support rollback.  But supporting rollback for a
>>> BlobDataManager is non-trivial because you'd need to make copies of
>>> all writable blobs involved in the transaction and maintain the file
>>> position state for all writeable and readable blobs in order to roll
>>> back to exactly that state.
>> Why not make the additional wrapper transparent as
>> soon the object is written (i.e. directly read (and write)
>> from the underlying storage, once the object was modified).
>Sorry, I'm afraid I don't understand the suggestion.  Could you say  
>it a different way?

As I understood your explanation (I never looked at the implementation):

  *  blob support is implemented on top of a normal storage

  *  you are lazy to implement savepoints in this blob layer

My suggestions for this case:

  *  let work your blob layer as it does now until it
     observes both a write and a savepoint

  *  at this point, it clears the data it may maintain and
     rereads it from the storage (which is savepoint capabable).

You will loose your blob optimizations in the rare case that
the blob was both written and savepointed.

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to