Hi, I'm new to Zope, and I've inherited a project with a bug that I've been unable to solve for a couple of days. Please excuse any wrong-terminology. There is a zope installation, with two containers under the root folder. In each of these there is an external method having the same name, 'search'. On the public side of the site its clear that, on occaision, the wrong one of these external methods is called. Root A methx_search B methx_search The methx's contain sql statements pointing to different databases, and the error messages I get are sql errors ( 'no column ...' ), which is why its pretty clear which one is being called. I couldn't find any obvious reason why the wrong one was being called, but I found I could disambiguate the external methods by renaming them A_methx_search and B_methx_search in the ZMI, and saving the methods to reload them. This worked, albeit proving I don't understand the root of the problem, however... The customer installation of this only includes the .pyc files that contain the external methods. When I try to rename and reload with the .pyc files only in the Extensions folder the problem does not get solved. When I remove the .pyc files and put the original .py files in place, everything works fine. What is going on? Finally, when I have .py files only, no .pyc files are generated, which I find slightly confusing. Thanks, Richard
On Wed, Feb 04, 2004 at 12:20:17PM +0000, Richard Jolly wrote:
Hi,
I'm new to Zope, and I've inherited a project with a bug that I've been unable to solve for a couple of days. Please excuse any wrong-terminology.
There is a zope installation, with two containers under the root folder. In each of these there is an external method having the same name, 'search'. On the public side of the site its clear that, on occaision, the wrong one of these external methods is called.
Root A methx_search B methx_search
The methx's contain sql statements pointing to different databases, and the error messages I get are sql errors ( 'no column ...' ), which is why its pretty clear which one is being called.
I couldn't find any obvious reason why the wrong one was being called, but I found I could disambiguate the external methods by renaming them A_methx_search and B_methx_search in the ZMI, and saving the methods to reload them. This worked, albeit proving I don't understand the root of the problem, however...
It's almost certainly incorrect use of acquisition. Can't say for sure without seeing how exactly you call these methods. That's the problem with acquisition - it's easy to set up something that *usually* works... I would stick with your solution of using distinct names.
The customer installation of this only includes the .pyc files that contain the external methods. When I try to rename and reload with the .pyc files only in the Extensions folder the problem does not get solved. When I remove the .pyc files and put the original .py files in place, everything works fine. What is going on?
ermm... no idea. by the way, .pyc files don't protect your code very well, if that's why you're shipping only them. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's JONIC LIMP BIMBO! (random hero from isometric.spaceninja.com)
Paul Winkler wrote:
On Wed, Feb 04, 2004 at 12:20:17PM +0000, Richard Jolly wrote:
Hi,
I'm new to Zope, and I've inherited a project with a bug that I've been unable to solve for a couple of days. Please excuse any wrong-terminology.
There is a zope installation, with two containers under the root folder. In each of these there is an external method having the same name, 'search'. On the public side of the site its clear that, on occaision, the wrong one of these external methods is called.
Root A methx_search B methx_search
The methx's contain sql statements pointing to different databases, and the error messages I get are sql errors ( 'no column ...' ), which is why its pretty clear which one is being called.
I couldn't find any obvious reason why the wrong one was being called, but I found I could disambiguate the external methods by renaming them A_methx_search and B_methx_search in the ZMI, and saving the methods to reload them. This worked, albeit proving I don't understand the root of the problem, however...
It's almost certainly incorrect use of acquisition. Can't say for sure without seeing how exactly you call these methods. That's the problem with acquisition - it's easy to set up something that *usually* works... I would stick with your solution of using distinct names.
It turns out that renaming, via the ZMI, the external methods is not sufficient. They still get confused. Presumably if I rename the methods is the py files this would finally eliminate the problem.
The customer installation of this only includes the .pyc files that contain the external methods. When I try to rename and reload with the .pyc files only in the Extensions folder the problem does not get solved. When I remove the .pyc files and put the original .py files in place, everything works fine. What is going on?
ermm... no idea.
I've found a reference to an old zope bug that sounds similar to my problem that was rejected: http://zope.org/Collectors/Zope/29 however the rejection doesn't throw any light on the py/pyc issue.
by the way, .pyc files don't protect your code very well, if that's why you're shipping only them.
I know - again, I plead "inherited project, not my fault". What I'd really like is to find a fix through the ZMI, because then I don't have to redistribute anything to the customer, and they don't have to reinstall, etc. Thanks for you help, I'll go back to reading about aquisition. Richard
On Thu, Feb 05, 2004 at 04:44:06PM +0000, Richard Jolly wrote:
It turns out that renaming, via the ZMI, the external methods is not sufficient. They still get confused. Presumably if I rename the methods is the py files this would finally eliminate the problem.
This is very doubtful. The function names in Extentions/*.py should be irrelevant to all objects other than the External Method itself. When a Zope object calls an external method, it does so by the name of the external method in the ZMI. At this point, still knowing nothing about your application, I wonder if there is another layer of indirection involved where the confusion happens. You have two differently-named external methods; therefore you can only get the wrong one if you ask for the wrong one; therefore, the error must be elsewhere than in the external methods. Make sure you really understand which objects are calling the external methods and when. Is there one object that decides which one to call? Is there a cache manager caching this object? Or are there multiple objects that call the ext. methods? -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's ELECTRO-RANDY COMBUSTION REACTION! (random hero from isometric.spaceninja.com)
Paul Winkler wrote: First, thanks for you help and patience.
On Thu, Feb 05, 2004 at 04:44:06PM +0000, Richard Jolly wrote:
It turns out that renaming, via the ZMI, the external methods is not sufficient. They still get confused. Presumably if I rename the methods is the py files this would finally eliminate the problem.
This is very doubtful.
I have to agree - its a thousand times more likely that there is a problem with the application code than with Zope.
The function names in Extentions/*.py should be irrelevant to all objects other than the External Method itself. When a Zope object calls an external method, it does so by the name of the external method in the ZMI.
Yes - again, my unfamiliarity with Zope will show through - but I am experiencing very odd behaviour. I have renamed the methods (changed the ids) within the ZMI, and saved the methods to refresh them (and restarted Zope, just to be sure). (I have no idea if this is relevant, but I can only rename in the ZMI by ticking the checkbox of the external method and clicking 'rename'. If I try and do it by clicking through to the external method object, changing the id and clicking 'save changes' it just doesn't take.) If the .py files are in the Extensions folder, then this works fine. If, however, only the .pyc files are in, then I get the same behaviour as before. It appears that the wrong method is called - however perhaps the right method (by name) is called, but the wrong code is associated with it, because it can't be loaded from the .pyc file or some such. Can the reload be silently failing for a pyc file? These errors are triggered by the call to the second external method sharing the same function name that is called. It doesn't matter which is called first, but when the second is called, it fails and will consistently fail from then on. There is another wrinkle. There are two identically named functions in the .py files. One of these is unused. Root A/ methx_strange id = methx_strange module = foo.py name = strange B/ other external methods foo.py def strange bar.py def strange On occaision bar.py's strange method is called. How can this be? I'm at a loss to explain this unless somehow the module name is not used.
At this point, still knowing nothing about your application, I wonder if there is another layer of indirection involved where the confusion happens. You have two differently-named external methods; therefore you can only get the wrong one if you ask for the wrong one; therefore, the error must be elsewhere than in the external methods.
Its quite simple, although not well coded.
Make sure you really understand which objects are calling the external methods and when. Is there one object that decides which one to call? Is there a cache manager caching this object? Or are there multiple objects that call the ext. methods?
They are called on form submissions, eg action="ext_meth_name". From what I can see there is no deliberate caching. The logs (DETAILED_LOG_FILE form z2.py) give the post data as /folder/ext_meth_name , which seems appropriate. There are no arguments to the methods (they get their data from self.REQUEST). I'm sure I don't understand half as much as I should. Is there an easy way to get all information about the context/caller of an external method? Info I should have mentioned earlier: Zope Version Zope 2.3.2 (binary release, python 1.5.2, win32-x86) Python Version 1.5.2 (#0, Jul 30 1999, 09:52:18) [MSC 32 bit (Intel)] System Platform win32 Thanks very much for your help with this, -- Richard Jolly
On Fri, Feb 06, 2004 at 04:18:56PM +0000, Richard Jolly wrote:
If the .py files are in the Extensions folder, then this works fine. If, however, only the .pyc files are in, then I get the same behaviour as before. It appears that the wrong method is called - however perhaps the right method (by name) is called, but the wrong code is associated with it, because it can't be loaded from the .pyc file or some such. Can the reload be silently failing for a pyc file?
Are you sure those .pyc files are correct? I believe Zope doesn't normally write .pyc files for external methods.
These errors are triggered by the call to the second external method sharing the same function name that is called. It doesn't matter which is called first, but when the second is called, it fails and will consistently fail from then on.
There is another wrinkle.
There are two identically named functions in the .py files. One of these is unused.
Root A/ methx_strange id = methx_strange module = foo.py name = strange B/ other external methods
foo.py def strange
bar.py def strange
On occaision bar.py's strange method is called. How can this be?
I'm at a loss to explain this unless somehow the module name is not used.
Fortunately, that is not possible :-)
I'm sure I don't understand half as much as I should. Is there an easy way to get all information about the context/caller of an external method?
You could have the ext. method return str(REQUEST) as part of its output. Maybe also self.getPhysicalPath() which should tell you something about the calling context.
Info I should have mentioned earlier:
Zope Version Zope 2.3.2 (binary release, python 1.5.2, win32-x86)
You do realize that's three years old, right? It is certainly possible that this is an old long-solved bug, but I have no knowledge of that. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's NEGA CLOWN OF DISASTER! (random hero from isometric.spaceninja.com)
Paul Winkler wrote:
On Fri, Feb 06, 2004 at 04:18:56PM +0000, Richard Jolly wrote:
If the .py files are in the Extensions folder, then this works fine. If, however, only the .pyc files are in, then I get the same behaviour as before. It appears that the wrong method is called - however perhaps the right method (by name) is called, but the wrong code is associated with it, because it can't be loaded from the .pyc file or some such. Can the reload be silently failing for a pyc file?
Are you sure those .pyc files are correct? I believe Zope doesn't normally write .pyc files for external methods.
I did check. The .pyc files were compiled elsewhere and put in place as a 'security' measure, or something like that. (Which caused an earlier part of my confusion because the zope errors would report file paths that I knew did not exist on the system. They turned out to be the location at which the .pyc files were created.)
These errors are triggered by the call to the second external method sharing the same function name that is called. It doesn't matter which is called first, but when the second is called, it fails and will consistently fail from then on.
There is another wrinkle.
There are two identically named functions in the .py files. One of these is unused.
Root A/ methx_strange id = methx_strange module = foo.py name = strange B/ other external methods
foo.py def strange
bar.py def strange
On occaision bar.py's strange method is called. How can this be?
I'm at a loss to explain this unless somehow the module name is not used.
Fortunately, that is not possible :-)
Thats good news - one less problem to think about ;-)
I'm sure I don't understand half as much as I should. Is there an easy way to get all information about the context/caller of an external method?
You could have the ext. method return str(REQUEST) as part of its output. Maybe also self.getPhysicalPath() which should tell you something about the calling context.
This was very helpful - although didn't acutally enlighten me.
Info I should have mentioned earlier:
Zope Version Zope 2.3.2 (binary release, python 1.5.2, win32-x86)
You do realize that's three years old, right? It is certainly possible that this is an old long-solved bug, but I have no knowledge of that.
I know, I know. Unfortunately I don't have any control over this. I did find a bug report that may be related. It was rejected as not being a bug - kind of like my situation :) http://zope.org/Collectors/Zope/29 Anyway, the solution I've come to is to import new .zexp files with the external method names changed to prevent conflicts, and put the .py files in place to be sure the external methods load. If I had time and a little more Zope patience I'd attempt to create a test case to see if there really was a problem besides a lack of understanding of aquisition. Luckily for me this chapter is considered closed, and I can return to work about which, hopefully, I am not so clueless. Thanks very much for you help, -- Richard Jolly
Richard Jolly wrote at 2004-2-4 12:20 +0000:
... Root A methx_search B methx_search
The methx's contain sql statements pointing to different databases, and the error messages I get are sql errors ( 'no column ...' ), which is why its pretty clear which one is being called.
I couldn't find any obvious reason why the wrong one was being called, but I found I could disambiguate the external methods by renaming them A_methx_search and B_methx_search in the ZMI, and saving the methods to reload them. This worked, albeit proving I don't understand the root of the problem, however...
You want to understand how acquisition works. Especially, you want to focus on "Containment before Context". Google to find relevant documents...
... Finally, when I have .py files only, no .pyc files are generated, which I find slightly confusing.
External Methods do not use Python's normal import facility but instead read in the methods. That's why no "*.pyc" files are generated. -- Dieter
participants (3)
-
Dieter Maurer -
Paul Winkler -
Richard Jolly