[ZODB-Dev] Implementing Storage Decorators

[Christian Theune]

Am Freitag, den 04.05.2007, 23:54 -0400 schrieb Jim Fulton:
> All of the examples I mentioned can be handled very well with a  
> decorator model.

Yup. My experience with using the proxy approach for is good as well (I
worked on the BlobStorage).

I'm kind of leaning towards using a proxy approach instead of spelling
everything out. I'm not completely convinced that spelling all methods
that are copied out is a good thing.

If storages have additional methods than it's unclear to me whether it
is better that those would not be available or not.

For example, IBLOBStorage defines the "storeBlob" method. Storages do
not have to provide this method but then they can't store Blobs. 

I can imagine multiple cases here:

1. Everything is automatically proxied and a method is invoked that your
storage doesn't know about (good thing)

  - the method still works, but you don't get the benefits of
    your proxy storage

2. Everything is automatically proxied and a method is invoked that your
storage doesn't know about (bad thing)

  - your proxy keeps assumptions about the state of the proxied
    storage which get out of sync because of the unknown method

3. Everything has to be manually proxied and a method is invoked that
your storage doesn't know about (semi-good thing)

  - your storage fails during tests and you see that you have to
    support (yet) another method

4. Everything has to be manually proxied and a method is invoked that
your storage doesn't know about (bad thing)

  - you notice during production that your proxy is not
    "certified" with a certain other storage because it uses a
    method you didn't know about. your database fails.

  - your proxy ends up knowing about all other storages (and all
    other proxy storages) and is very painful to maintain

Hmm. In conclusion I have the feeling that deviating from the normal
storage interface shouldn't happen too much. Anyway, the DB class and
Connection class are the ones dealing with the Storage anyway ... Any
additional methods should probably only be for maintenance and keep the
existing methods working in an idempotent way.

Christian

-- 
gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/zodb-dev/attachments/20070505/bf0ac8f5/attachment.bin