[Grok-dev] Dolmen and its releases
trollfot at gmail.com
Fri Oct 23 06:55:18 EDT 2009
What you say only worths for the Blobs.
For a non-blob file, it makes sense to keep a separate file.
It's easy to provide a non Persistent version of a blob
It's not for a File, since zope.app.file inherit itself from Persistent.
There is at least on interest motivating a separate blob object,
containing a Blob:
It can be moved out of your object and act as a normal object.
That being, providing a "BlobValue" is trivial
providing a FileValue is senseless
I wonder what the performace impact is, keeping a BlobFile with an
independant connection as an attribute.
It can think of several usecases, that would modify the BlobFile
itself and not the object containing it.
How do you solve that, in Plone, to handle an object containing a
named blob file ?
I didn't see any solution provided for that in plone.namedfile
2009/10/23 Martin Aspeli <optilude+lists at gmail.com>:
> Souheil CHELFOUH wrote:
>> After discussing this matter with several persons, it appears that the
>> fact the File has its own _p_jar is not really a problem.
>> As the file is often a "big" chunk of data, it makes sense to has a
>> separate object, in the zope point of view, so when you load our
>> object containing a file, you don't load the file with it.
>> Performance wise, i'd say it doesn't have a negative impact, it's more
>> than balance by that situation.
>> What do you guys think ?
> I think it depends on your use case:
> - if you've got a big file, it should be a blob; in this case, the
> blob container (which also stores filename etc) probably shouldn't be a
> separate persistent object, since the blob is one already.
> - if you have a small file and you will render its contents often when
> the object is loaded, avoiding a separate object load may be beneficial
> Author of `Professional Plone Development`, a book for developers who
> want to work with Plone. See http://martinaspeli.net/plone-book
> Grok-dev mailing list
> Grok-dev at zope.org
More information about the Grok-dev