Jim Washington, on 2008-01-19:

David Bear wrote:

...

I'm doing my first zeo setup, and suddenly I'm not sure about my products directory. Do I put all products in a products directory of the zeo server or in each zope instance?

IIRC, Products go in each zope instance. The zeo instance gets the ZODB.

Correct. And there is nothing wrong with using the same Products directory for all zope instances (well, you would call them zeo clients really). So: make the Products directory of the second instance a symbolic link to the first one. Or edit the zope.conf file of the second one and point to the Products dir of the first one in the products directive. -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl]

On Jan 19, 2008, at 1:39 PM, Dieter Maurer wrote:

Tres Seaver wrote at 2008-1-18 21:06 -0500:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

David Bear wrote:

...

I'm doing my first zeo setup, and suddenly I'm not sure about my products directory. Do I put all products in a products directory of the zeo server or in each zope instance?

Normally the ZEO server doesn't need to have access to the products, which are "application code". The only exception is for products which define classes having application-level conflict resolution: in such cases, the ZEO server must be able to import the product (or else the conflict resolution code is not consulted).

As an additional note:

Zope uses Python import magic to make packages available in "INSTANCE_HOME/Products" as additional products in the "Products" package.

If some of these products need application specific conflict resolution, the ZEO server needs to activate this import magic -- by importing Zope's "App.FindHomes".

An patch to runzeo that allows INSTANCE_HOME Products to be put on the path (but does not require Zope's App.FindHomes is here): https://bugs.launchpad.net/zope2/+bug/143770 Using this patch, you can create a Products directory in your ZEO's instance home and put products in there to service conflict resolution while still keeping SOFTWARE_HOME products on the path. Importing App.FindHomes might be a better way to do this. - C

On Jan 29, 2008, at 1:19 AM, Ricardo Newbery wrote:

On Jan 19, 2008, at 10:39 AM, Dieter Maurer wrote:

...

Zope uses Python import magic to make packages available in "INSTANCE_HOME/Products" as additional products in the "Products" package.

If some of these products need application specific conflict resolution, the ZEO server needs to activate this import magic -- by importing Zope's "App.FindHomes".

-- Dieter

Dieter,

Apologies for jumping late in this thread but how precisely should "App.FindHomes" be imported?

And a related question. Any suggestions on how to support multiple product directories like a non-zeo config? I checked already and zeo.conf doesn't appear to support the "products" directive.

Ric

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? Ric

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

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

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

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

Peter Bengtsson wrote:

Chris McDonough wrote:

...

Ricardo Newbery wrote:

...

On Jan 30, 2008, at 12:59 PM, Tres Seaver wrote:

[snip]

...

- C

A HA!! That's where that notorious `-C` comes from that we all see in the str(REQUEST) on the REQUEST.form part! It's Chris secretly influencing our apache rewrite rules somehow.

Dammit! You figured it out... ;-) - C

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

Ricardo Newbery wrote at 2008-1-29 01:19 -0800:

... Apologies for jumping late in this thread but how precisely should "App.FindHomes" be imported?

Someone else reported about a ZEO patch that does the same thing without a need to import "App.FindHomes". If you have Zope installed and ZEO is running in the Zope installation (shares its code), then "import App.FindHomes" in sufficient to import "App.FindHomes".

And a related question. Any suggestions on how to support multiple product directories like a non-zeo config? I checked already and zeo.conf doesn't appear to support the "products" directive.

"App.FindHomes" can be controlled via the envvar "PRODUCTS_PATH". If defined, it is a "pathsep" separated sequence of directories where Zope should look for products. It may contain "%(XXXX)s" patterns with "XXXX" from "PRODUCTS_PATH", "SOFTWARE_PRODUCTS" and "INSTANCE_PRODUCTS". In these cases, the pattern is replaced by the corresponding path. -- Dieter

On Jan 30, 2008, at 10:42 AM, Dieter Maurer wrote:

Ricardo Newbery wrote at 2008-1-29 01:19 -0800:

...

... Apologies for jumping late in this thread but how precisely should "App.FindHomes" be imported?

Someone else reported about a ZEO patch that does the same thing without a need to import "App.FindHomes".

If you have Zope installed and ZEO is running in the Zope installation (shares its code), then "import App.FindHomes" in sufficient to import "App.FindHomes".

Any plans to incorporate either of these solutions in the next release? I would like to avoid trying to explain how to do this to users of a third-party product that needs to be accessible to ZEO.

...

And a related question. Any suggestions on how to support multiple product directories like a non-zeo config? I checked already and zeo.conf doesn't appear to support the "products" directive.

"App.FindHomes" can be controlled via the envvar "PRODUCTS_PATH". If defined, it is a "pathsep" separated sequence of directories where Zope should look for products. It may contain "%(XXXX)s" patterns with "XXXX" from "PRODUCTS_PATH", "SOFTWARE_PRODUCTS" and "INSTANCE_PRODUCTS". In these cases, the pattern is replaced by the corresponding path.

Ahh... this sounds good. So, assuming App.FindHomes in imported, then all I would need to explain is how to add the necessary "export" lines to zeo.conf? (or maybe zeoctl?) Thanks, Ric