On 9 May 2011 13:32, Hanno Schlichting <ha...@hannosch.eu> wrote:
> On Mon, May 9, 2011 at 2:26 PM, Laurence Rowe <l...@lrowe.co.uk> wrote:
>> While looking at the Plone versioning code the other day, it struck me
>> that it would be much more efficient to implement file versioning if
>> we could rely on blobs never changing after their first commit, as a
>> copy of the file data would not need to be made proactively in the
>> versioning repository incase the blob was changed in a future
>> transaction.
>> Subclassing of blobs is not supported, but looking at the code I
>> didn't see anything that actively prevented this other than the
>> Blob.__init__ itself. Is there something I've missed here? I had
>> thought that an ImmutableBlob could be implemented by overriding the
>> open and consumeFile methods of Blob to prevent modification after
>> first commit.
> I thought blobs are always immutable by design?

Blobs can be opened writable in subsequent transactions with
blob.open('w'). This leads to the blob storage creating a new file
when the transaction is committed - the naming scheme is basically

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to