Re: [ZODB-Dev] Implementing Storage Decorators
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 - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Implementing Storage Decorators
On May 4, 2007, at 3:52 PM, Tino Wildenhain wrote: Dieter Maurer schrieb: Jim Fulton wrote at 2007-5-4 14:40 -0400: On May 4, 2007, at 2:33 PM, Dieter Maurer wrote: Jim Fulton wrote at 2007-5-2 11:52 -0400: ... I think I still rather like explicit, but I'm on the fence about which approach is best. What do other people think? From your description, I would use a subclassing (and forget about proxy and copying). That would be a nightmare, on multiple levels: - All of the separate implementations would become tightly coupled, which is what happens with inheritance. - Either someone would have to create classes for the various permutations of features, or consumers would have to mix and match multiple classes to get what they want and sort out the variate internal implementation incompatibilities. Your decorators would become mixin classes and the final classes would list the features they like -- simpler than ZCML binding together... Of course, some features may not play well with one another. But, that will make problems also with proxies or copying... Even this could be sorted out with special cleanup or secure mixins which can do dirty tricks like accessing self.__class__.__bases__ to fixup ;) (Much like combining the copy with the subclass approach) Uh huh. I'm for mixin with strong guidelines on implementation (e.g. how to call private attributes to not pollute the namespace) Forget it. Inheritance is not an option. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Implementing Storage Decorators
On May 4, 2007, at 3:14 PM, Dieter Maurer wrote: Jim Fulton wrote at 2007-5-4 14:40 -0400: On May 4, 2007, at 2:33 PM, Dieter Maurer wrote: Jim Fulton wrote at 2007-5-2 11:52 -0400: ... I think I still rather like explicit, but I'm on the fence about which approach is best. What do other people think? From your description, I would use a subclassing (and forget about proxy and copying). That would be a nightmare, on multiple levels: - All of the separate implementations would become tightly coupled, which is what happens with inheritance. - Either someone would have to create classes for the various permutations of features, or consumers would have to mix and match multiple classes to get what they want and sort out the variate internal implementation incompatibilities. Your decorators would become mixin classes and the final classes would list the features they like So the second case above. As I said, inheritance causes tight coupling. Mix in classes can work when the features provides are truly independent. That would certainly not be the case here. Trying to combine multiple storage implementations in a single class would be a real mess. -- simpler than ZCML binding together... There's no ZCML involved here, although there would likely be ZConfig files. People would want to be able to combine storages in their configuration files. Of course, some features may not play well with one another. But, that will make problems also with proxies or copying... All of the examples I mentioned can be handled very well with a decorator model. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Implementing Storage Decorators
Dieter Maurer schrieb: Jim Fulton wrote at 2007-5-4 14:40 -0400: On May 4, 2007, at 2:33 PM, Dieter Maurer wrote: Jim Fulton wrote at 2007-5-2 11:52 -0400: ... I think I still rather like explicit, but I'm on the fence about which approach is best. What do other people think? From your description, I would use a subclassing (and forget about proxy and copying). That would be a nightmare, on multiple levels: - All of the separate implementations would become tightly coupled, which is what happens with inheritance. - Either someone would have to create classes for the various permutations of features, or consumers would have to mix and match multiple classes to get what they want and sort out the variate internal implementation incompatibilities. Your decorators would become mixin classes and the final classes would list the features they like -- simpler than ZCML binding together... Of course, some features may not play well with one another. But, that will make problems also with proxies or copying... Even this could be sorted out with special cleanup or secure mixins which can do dirty tricks like accessing self.__class__.__bases__ to fixup ;) (Much like combining the copy with the subclass approach) I'm for mixin with strong guidelines on implementation (e.g. how to call private attributes to not pollute the namespace) Regards Tino ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Implementing Storage Decorators
Jim Fulton wrote at 2007-5-4 14:40 -0400: > >On May 4, 2007, at 2:33 PM, Dieter Maurer wrote: > >> Jim Fulton wrote at 2007-5-2 11:52 -0400: >>> ... >>> I think I still rather like explicit, but I'm on the fence about >>> which approach is best. What do other people think? >> >>> From your description, I would use a subclassing (and forget about >> proxy and copying). > >That would be a nightmare, on multiple levels: > >- All of the separate implementations would become tightly coupled, >which is what happens with inheritance. > >- Either someone would have to create classes for the various >permutations of features, or consumers would have to mix and match >multiple classes to get what they want and sort out the variate >internal implementation incompatibilities. Your decorators would become mixin classes and the final classes would list the features they like -- simpler than ZCML binding together... Of course, some features may not play well with one another. But, that will make problems also with proxies or copying... -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Implementing Storage Decorators
On May 4, 2007, at 2:33 PM, Dieter Maurer wrote: Jim Fulton wrote at 2007-5-2 11:52 -0400: ... I think I still rather like explicit, but I'm on the fence about which approach is best. What do other people think? From your description, I would use a subclassing (and forget about proxy and copying). That would be a nightmare, on multiple levels: - All of the separate implementations would become tightly coupled, which is what happens with inheritance. - Either someone would have to create classes for the various permutations of features, or consumers would have to mix and match multiple classes to get what they want and sort out the variate internal implementation incompatibilities. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Implementing Storage Decorators
Jim Fulton wrote at 2007-5-2 11:52 -0400: > ... >I think I still rather like explicit, but I'm on the fence about >which approach is best. What do other people think? >From your description, I would use a subclassing (and forget about proxy and copying). -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
