Re: [ZODB-Dev] Immutable blobs?
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? Hanno ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Immutable blobs?
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
oid/tid.blob.
Laurence
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Immutable blobs?
On Mon, May 9, 2011 at 8:26 AM, 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? Nope. Subclassing blobs is *explicitly* not supported. I had thought that an ImmutableBlob could be implemented by overriding the open and consumeFile methods of Blob to prevent modification after first commit. If you want to implement a restriction like this, do it in a wrapper class. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
