Re: [Zope] Re: Zeo and conflict resolution (was suddenly confused)
Ricardo Newbery wrote at 2008-1-30 13:14 -0800: ... I meant easier for the end user, not the developer. It's kind of complicated right now to explain how to set up a ZEO configuration to work with your third-party product. Makes it a bit of hurdle to distribute such a thing for general use. Loby Jim that he accepts the patch. -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Zeo and conflict resolution (was suddenly confused)
Ricardo Newbery wrote at 2008-1-30 12:24 -0800: ... Has anyone given thought to maybe providing a more general class with conflict resolution in the core distribution? There can be no *general* class with conflict resolution. Conflicts usually are fatal. Precise knowledge about the intended use is necessary to determine whether and how a conflict can be resolved. Take a look at the Length class. It resolves all conflicts in a way compatible with maintaining the length of a data structure. However, you must *NOT* use it to assign unique integer tickets as it may return the same value in different threads. Without conflict resolution you would get a conflict when different threads take a ticket concurrently; with the Lenght conflict resolution, the tickets are no longer unique. -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Zeo and conflict resolution (was suddenly confused)
On Jan 30, 2008, at 9:32 AM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ricardo Newbery wrote: Another related question. With respect to conflict resolution, is is safe to assume that products (with _p_resolveConflict methods) in the main Zope products directory are already available to the ZEO server without any special configuration? Only if you installed the ZEO server instance from a Zope software; if you installed it via a ZODB-only installation, then the products won't be available (because they aren't shipped with the standalone ZODB tarball). Thanks. Okay, then assuming you've installed ZEO from Zope software, if your third-party product includes conflict resolution by instantiating a class defined in the Zope product directory, then is it also safe to assume that this product resolution is still available to the ZEO server? For example, if I have the following in MyProduct: from BTrees import Length class MyClass(...): _count = None def incrementCount(self): if self._count is None: self._count = Length.Length() self._count.change(1) def getCount(self): return self._count() Then do I have to make MyProduct.MyClass available to ZEO or is it enough that BTrees.Length is available? Ric ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Zeo and conflict resolution (was suddenly confused)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ricardo Newbery wrote: Okay, then assuming you've installed ZEO from Zope software, if your third-party product includes conflict resolution by instantiating a class defined in the Zope product directory, then is it also safe to assume that this product resolution is still available to the ZEO server? For example, if I have the following in MyProduct: from BTrees import Length class MyClass(...): _count = None def incrementCount(self): if self._count is None: self._count = Length.Length() self._count.change(1) def getCount(self): return self._count() Then do I have to make MyProduct.MyClass available to ZEO or is it enough that BTrees.Length is available? That is enough: the Length class derives from Persistent, which means that handle their own conflict resolution: as long as your product doss no conflict resolution of its own, it doesn't need to be imported by the storage server. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHoM1P+gerLs4ltQ4RAhvmAJ0UFSz0EC+uO926RNIJviXl+2spWACfT62H 9CCDJ5vj+37LgnSASYUFQWw= =8qmF -END PGP SIGNATURE- ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Zeo and conflict resolution (was suddenly confused)
On Jan 30, 2008, at 11:17 AM, Tres Seaver wrote: Ricardo Newbery wrote: Okay, then assuming you've installed ZEO from Zope software, if your third-party product includes conflict resolution by instantiating a class defined in the Zope product directory, then is it also safe to assume that this product resolution is still available to the ZEO server? For example, if I have the following in MyProduct: from BTrees import Length class MyClass(...): _count = None def incrementCount(self): if self._count is None: self._count = Length.Length() self._count.change(1) def getCount(self): return self._count() Then do I have to make MyProduct.MyClass available to ZEO or is it enough that BTrees.Length is available? That is enough: the Length class derives from Persistent, which means that handle their own conflict resolution: as long as your product doss no conflict resolution of its own, it doesn't need to be imported by the storage server. Tres. Great, thanks. Has anyone given thought to maybe providing a more general class with conflict resolution in the core distribution? The Length class works for simple counters and I guess it can also be used for just simple assignments, but what about something more complicated, perhaps with some sort of factory defined at the moment of instantiation? Assuming this is even possible, having such a general purpose conflict resolution class defined in the Zope products directory might make it easier to distribute a third-party product that needs a little conflict resolution. Just a thought. Ric ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Zeo and conflict resolution (was suddenly confused)
On Jan 30, 2008, at 12:59 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ricardo Newbery wrote: Has anyone given thought to maybe providing a more general class with conflict resolution in the core distribution? The Length class works for simple counters and I guess it can also be used for just simple assignments, but what about something more complicated, perhaps with some sort of factory defined at the moment of instantiation? Assuming this is even possible, having such a general purpose conflict resolution class defined in the Zope products directory might make it easier to distribute a third-party product that needs a little conflict resolution. Just a thought. Custom CR code is *hard* to get right: most people would be better off using stock code (e.g., on of the tree types defined in the BTrees package, or Length). Those who can get it right aren't likely to need their hands held. ;) I meant easier for the end user, not the developer. It's kind of complicated right now to explain how to set up a ZEO configuration to work with your third-party product. Makes it a bit of hurdle to distribute such a thing for general use. Oops, I just realized that Length won't work for simple assignments as the conflict resolution assumes it's trying to resolve a counter (which should have been obvious, I know). Is there zope core class I can use for a simple assignment, that maybe resolves conflicts by just picking the last value assigned? Ric ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Zeo and conflict resolution (was suddenly confused)
Ricardo Newbery wrote: On Jan 30, 2008, at 12:59 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ricardo Newbery wrote: Has anyone given thought to maybe providing a more general class with conflict resolution in the core distribution? The Length class works for simple counters and I guess it can also be used for just simple assignments, but what about something more complicated, perhaps with some sort of factory defined at the moment of instantiation? Assuming this is even possible, having such a general purpose conflict resolution class defined in the Zope products directory might make it easier to distribute a third-party product that needs a little conflict resolution. Just a thought. Custom CR code is *hard* to get right: most people would be better off using stock code (e.g., on of the tree types defined in the BTrees package, or Length). Those who can get it right aren't likely to need their hands held. ;) I meant easier for the end user, not the developer. It's kind of complicated right now to explain how to set up a ZEO configuration to work with your third-party product. Makes it a bit of hurdle to distribute such a thing for general use. Oops, I just realized that Length won't work for simple assignments as the conflict resolution assumes it's trying to resolve a counter (which should have been obvious, I know). Is there zope core class I can use for a simple assignment, that maybe resolves conflicts by just picking the last value assigned? There is no such thing as the last value during a conflict (only three states: what's in the database, and the two conflicting states: what connection1 says, and what connection2 says). If the values are always going to have a __cmp__ method or if they can be otherwise compared (like integers), and if you're willing to accept the highest of the three states, you might use the conflict resolution policy of Products.Transience.Transience.py.Increaser. - C ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Zeo and conflict resolution (was suddenly confused)
On Jan 30, 2008, at 1:39 PM, Chris McDonough wrote: Ricardo Newbery wrote: On Jan 30, 2008, at 12:59 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ricardo Newbery wrote: Has anyone given thought to maybe providing a more general class with conflict resolution in the core distribution? The Length class works for simple counters and I guess it can also be used for just simple assignments, but what about something more complicated, perhaps with some sort of factory defined at the moment of instantiation? Assuming this is even possible, having such a general purpose conflict resolution class defined in the Zope products directory might make it easier to distribute a third-party product that needs a little conflict resolution. Just a thought. Custom CR code is *hard* to get right: most people would be better off using stock code (e.g., on of the tree types defined in the BTrees package, or Length). Those who can get it right aren't likely to need their hands held. ;) I meant easier for the end user, not the developer. It's kind of complicated right now to explain how to set up a ZEO configuration to work with your third-party product. Makes it a bit of hurdle to distribute such a thing for general use. Oops, I just realized that Length won't work for simple assignments as the conflict resolution assumes it's trying to resolve a counter (which should have been obvious, I know). Is there zope core class I can use for a simple assignment, that maybe resolves conflicts by just picking the last value assigned? There is no such thing as the last value during a conflict (only three states: what's in the database, and the two conflicting states: what connection1 says, and what connection2 says). If the values are always going to have a __cmp__ method or if they can be otherwise compared (like integers), and if you're willing to accept the highest of the three states, you might use the conflict resolution policy of Products.Transience.Transience.py.Increaser. Great, that's exactly what I need. Thanks. I also noticed another interesting option for a counter at Products.Transience.Transience.Length2. Ric ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
