No module named GenericUserFolder
Hi, I wanted to follow the hint about customizing the cache of an ZSQL method given in the Zope Book at chapter Relational Databases. When I try to press the Advanced tab of a ZSQL method I get: Error Type: ImportError Error Value: No module named GenericUserFolder Regarding to http://www.zope.org/Members/Zen/GenericUserFolder it seems that this is a remainder from some previous code which should not really belong to Zope 2.6.1 which I'm using. Or is there any other problem? Kind regards Andreas.
Andreas Tille wrote at 2003-8-12 14:43 +0200:
I wanted to follow the hint about customizing the cache of an ZSQL method given in the Zope Book at chapter Relational Databases. When I try to press the Advanced tab of a ZSQL method I get:
Error Type: ImportError Error Value: No module named GenericUserFolder
Regarding to
http://www.zope.org/Members/Zen/GenericUserFolder
it seems that this is a remainder from some previous code which should not really belong to Zope 2.6.1 which I'm using. Or is there any other problem?
A bug in ZSQL Method code: It traverses the product and ZClass registry and chokes when it finds something not working. Instead, if should log the problem and then continue. Determine the line in the ZSQL Method code that causes the exception (you look at the traceback for this). Catch exceptions other then "ConflictError", log them and continue. File a bug report with patch. Alternative: Remove products which no longer work from "Control_Panel/Products". Dieter
On Tue, 12 Aug 2003, Dieter Maurer wrote:
Determine the line in the ZSQL Method code that causes the exception It happens on *any* (even the simplest) ZSQL Method on my installation.
(you look at the traceback for this). There isn't any hint in the HTML source of the error page (if you mean this). I would have mentioned this in my mail.
Catch exceptions other then "ConflictError", log them and continue. How to catch them in a plain ZSQL method???
File a bug report with patch. I would like to do the first. I would love to provide a patch but it seems to be out of my scope - sorry.
Alternative: Remove products which no longer work from "Control_Panel/Products". I'll check this.
Thanks for the hints Andreas.
Andreas Tille wrote at 2003-8-12 23:49 +0200:
On Tue, 12 Aug 2003, Dieter Maurer wrote:
Determine the line in the ZSQL Method code that causes the exception It happens on *any* (even the simplest) ZSQL Method on my installation.
Sure, as they all execute the same code when you press the "Advanced" tab.
(you look at the traceback for this). There isn't any hint in the HTML source of the error page (if you mean this).
From Zope 2.6.x on, the traceback is no longer in the HTML source. You find it via "/error_log" in your "Root Folder".
Catch exceptions other then "ConflictError", log them and continue. How to catch them in a plain ZSQL method???
It comes from Python code. The traceback tells you where. Dieter
On Wed, 13 Aug 2003, Dieter Maurer wrote:
From Zope 2.6.x on, the traceback is no longer in the HTML source. You find it via "/error_log" in your "Root Folder".
Exception Type ImportError Exception Value No module named GenericUserFolder Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec * Module Shared.DC.ZRDB.DA, line 483, in manage_product_zclass_info * Module ZODB.Connection, line 534, in setstate ImportError: No module named GenericUserFolder
Catch exceptions other then "ConflictError", log them and continue. How to catch them in a plain ZSQL method???
It comes from Python code. The traceback tells you where. Well, I did a
grep -R GenericUserFolder /usr/lib/zope/* which showed no result. I went once more throug my list of products and removed all those products which can not be found in /usr/lib/zope/lib/python/Products/ which were quiet a lot including some called Hotfix-<date>. I have to admit that it is quite hard to keep control of those products. These remainders were left behind by some Debian packages I installed once to test them and removed the packages afterwards. Now I've got those strange reminders. Is there any hint how to get rid of this more comfortably than just visually compare the Products folder in ZMI with the directory above? This would be a great help. After this cleanup I packed Zope database to really get those remainders removed (hopefully). I have to admit that the situation did not change. I always get the error message mentioned above. Further investigation showed that the string GenericUserFolder continues to stay in the Zope database: > grep -c GenericUserFolder Data.fs 6 Any idea who I could get rid of this??? In my opinion it is a Zope bug but I would like to ask people (especially on Debian systems) to verify this. Kind regards Andreas. BTW: I also checked STUPID_LOGFILE for further hints but there was no trace at all except of the error message mentioned above.
Andreas Tille wrote at 2003-8-14 10:56 +0200:
... problems with "Advanced" tab of Z SQL Methods ... ... Exception Type ImportError Exception Value No module named GenericUserFolder
Traceback (innermost last): ... * Module App.special_dtml, line 174, in _exec * Module Shared.DC.ZRDB.DA, line 483, in manage_product_zclass_info * Module ZODB.Connection, line 534, in setstate
ImportError: No module named GenericUserFolder
Catch exceptions other then "ConflictError", log them and continue. How to catch them in a plain ZSQL method???
It comes from Python code. The traceback tells you where. Well, I did a
grep -R GenericUserFolder /usr/lib/zope/*
which showed no result.
"Shared/DC/ZRDB/DA.py" (this contains the Z SQL Method implementation) line 483 is the place where you should place a "try: ... except: ..." around. Sure, you will *not* find a "GenericUserFolder" there. Zope tries to load an element from the ZODB (that is the "setstate" method in your traceback) which references "GenericUserFolder". You no longer have this product installed. Therefore, you get the ImportError. Dieter
On Thu, 14 Aug 2003, Dieter Maurer wrote:
Andreas Tille wrote at 2003-8-14 10:56 +0200:
... problems with "Advanced" tab of Z SQL Methods ... ... Exception Type ImportError Exception Value No module named GenericUserFolder
Traceback (innermost last): ... * Module App.special_dtml, line 174, in _exec * Module Shared.DC.ZRDB.DA, line 483, in manage_product_zclass_info * Module ZODB.Connection, line 534, in setstate
ImportError: No module named GenericUserFolder
"Shared/DC/ZRDB/DA.py" (this contains the Z SQL Method implementation) line 483 is the place where you should place a "try: ... except: ..." around. s/should/could/ I definitely will not do anything if I do not know exactly what I'm doing. That's why I only *could* change something if I would have some internal knowledge.
Sure, you will *not* find a "GenericUserFolder" there. Zope tries to load an element from the ZODB (that is the "setstate" method in your traceback) which references "GenericUserFolder". You no longer have this product installed. Therefore, you get the ImportError. In my opinion this means there is some bug regarding the referential integrity and this should be fixed at first before fixing the symptoms above. If there is a reference to a not existing object something is broken. Perhaps I misunderstood something and I'm requesting something which can not be implemented.
Is there any way to find out *which* element tries to reference "GenericUserFolder"? Kind regards Andreas.
Andreas Tille wrote at 2003-8-15 08:29 +0200:
...
* Module Shared.DC.ZRDB.DA, line 483, in manage_product_zclass_info * Module ZODB.Connection, line 534, in setstate
ImportError: No module named GenericUserFolder
"Shared/DC/ZRDB/DA.py" (this contains the Z SQL Method implementation) line 483 is the place where you should place a "try: ... except: ..." around. s/should/could/ I definitely will not do anything if I do not know exactly what I'm doing. That's why I only *could* change something if I would have some internal knowledge.
Fine. It may mean however, that you have to live with your problem...
Sure, you will *not* find a "GenericUserFolder" there. Zope tries to load an element from the ZODB (that is the "setstate" method in your traceback) which references "GenericUserFolder". You no longer have this product installed. Therefore, you get the ImportError. In my opinion this means there is some bug regarding the referential integrity and this should be fixed at first before fixing the symptoms above.
One of your ZODB objects references "GenericUserFolder" and you have it not longer installed ...
If there is a reference to a not existing object something is broken. Perhaps I misunderstood something and I'm requesting something which can not be implemented.
Is there any way to find out *which* element tries to reference "GenericUserFolder"?
You can use a debugger (--> see mailing list archives and HowTos) to analyse the object causing the exception. You should be able to find its class (I expect a ZClass) and its "_p_oid". Dieter
On Fri, 15 Aug 2003, Dieter Maurer wrote:
Fine. It may mean however, that you have to live with your problem... While I can cope perfectly with something which is no real problem for me I have to admit that this answer diverges slightly what I observed in the past at this list in special and other Free Software related lists in common.
I just try to gather information for a reasonable bug report which gives developers as much as possible relevant information.
One of your ZODB objects references "GenericUserFolder" and you have it not longer installed ... I think I have understand this and in my opinion it is a bug of Zope of the previous existance and later removal of any random product (while I do not realy know if "any random" is correct) leads to a situation that not obviousely related parts of Zope break functionality.
Please note: *I* can cope with *this* situation but I feel obliged to other users and developers to not to hide the knowledge.
You can use a debugger (--> see mailing list archives and HowTos) to analyse the object causing the exception. You should be able to find its class (I expect a ZClass) and its "_p_oid". Do you have any more explicite hint regarding debugging techniques? I just found to start Zope with -D option but I did not recognized any more explicite logs or error messages.
Kind regards Andreas.
Andreas Tille wrote:
I think I have understand this and in my opinion it is a bug of Zope of the previous existance and later removal of any random product (while I do not realy know if "any random" is correct) leads to a situation that not obviousely related parts of Zope break functionality.
So if you remove one wheel of a car you would expect the steering to continue to behave exactly as it did before? ;-)
Do you have any more explicite hint regarding debugging techniques?
Don't use ZClasses ;-) cheers, Chris
On Thu, 28 Aug 2003, Chris Withers wrote:
I think I have understand this and in my opinion it is a bug of Zope of the previous existance and later removal of any random product (while I do not realy know if "any random" is correct) leads to a situation that not obviousely related parts of Zope break functionality.
So if you remove one wheel of a car you would expect the steering to continue to behave exactly as it did before? ;-) Well, if you would have followed the thread I think the better comparison would be: If I put a suitcase into a car and remove the suitcase after I reached the place I wanted it to be transported I would expect the car to be working as before. :-P
Do you have any more explicite hint regarding debugging techniques?
Don't use ZClasses ;-) Hmmm, I never did I just installed the GenericUserFolder package ages ago installed it after some tests. Now some functionality of Zope is broken if as the suitcase removal would have taken one wheel ...
Kind regards Andreas.
Andreas Tille wrote:
Well, if you would have followed the thread I think the better comparison would be: If I put a suitcase into a car and remove the suitcase after I reached the place I wanted it to be transported I would expect the car to be working as before. :-P
Depends how much the suitcase weighed and whether it had big shiny spikes on the outside...
Hmmm, I never did I just installed the GenericUserFolder package ages ago installed it after some tests. Now some functionality of Zope is broken if as the suitcase removal would have taken one wheel ...
Interesting, I knew GUF was crufty, but I didn't know it could do that kind of damage... Chris
On Fri, 29 Aug 2003, Chris Withers wrote:
Well, if you would have followed the thread I think the better comparison would be: If I put a suitcase into a car and remove the suitcase after I reached the place I wanted it to be transported I would expect the car to be working as before. :-P
Depends how much the suitcase weighed and whether it had big shiny spikes on the outside... ACK, here. As a consequence perhaps we have to make the trunk of the car save against such kind of stuff by using some armour-plating o whatever inside.
Hmmm, I never did I just installed the GenericUserFolder package ages ago installed it after some tests. Now some functionality of Zope is broken if as the suitcase removal would have taken one wheel ...
Interesting, I knew GUF was crufty, but I didn't know it could do that kind of damage... Exactly this is the point I wanted to address in this tread: There are crufty products around (which can't be avoided) that can break Zopes internal functionality (which should be avoided as strong as possible).
Kind regards Andreas.
Andreas Tille wrote:
ACK, here. As a consequence perhaps we have to make the trunk of the car save against such kind of stuff by using some armour-plating o whatever inside.
Python Products have the equivalent of Superman's powers here, doesn't matter how strong you make that trunk...
Exactly this is the point I wanted to address in this tread: There are crufty products around (which can't be avoided) that can break Zopes internal functionality (which should be avoided as strong as possible).
Well, like I said, there's nothing Zope can (or should) do to prevent that, it's just up to you to do some sanity checks before you install a product which hasn't been touched in ages... I'd probabyl suggest a mail to this list asking if anyone else has had any problems, or maybe even a quick Google... Chris
Andreas Tille wrote at 2003-8-28 08:02 +0200:
On Fri, 15 Aug 2003, Dieter Maurer wrote:
Fine. It may mean however, that you have to live with your problem... While I can cope perfectly with something which is no real problem for me I have to admit that this answer diverges slightly what I observed in the past at this list in special and other Free Software related lists in common.
There is a limit on the amount of support you can expect....
I just try to gather information for a reasonable bug report which gives developers as much as possible relevant information.
One of your ZODB objects references "GenericUserFolder" and you have it not longer installed ... I think I have understand this and in my opinion it is a bug of Zope of the previous existance and later removal of any random product (while I do not realy know if "any random" is correct) leads to a situation that not obviousely related parts of Zope break functionality.
I have told you the fix for this bug in an earlier message. You did not want to accept it... I cannot do more for you.
Please note: *I* can cope with *this* situation but I feel obliged to other users and developers to not to hide the knowledge.
In fact, this same problem came up already in the mailing list. The poster then followed my advice and quickly could use his advanced tab again. He may have posted a bug report. I am sure, I suggested it to him. But, probably, you did not check the collector?
You can use a debugger (--> see mailing list archives and HowTos) to analyse the object causing the exception. You should be able to find its class (I expect a ZClass) and its "_p_oid". Do you have any more explicite hint regarding debugging techniques? I just found to start Zope with -D option but I did not recognized any more explicite logs or error messages.
I *never* search the archives or Zope.org for others. This is not my problem; it is yours! Dieter
On Tue, 12 Aug 2003, Dieter Maurer wrote:
Alternative: Remove products which no longer work from "Control_Panel/Products". I checked on another box which has thrwon some different Error Messages when I tried to adjust the cache. After having cleaned "Control_Panel/Products" which was a little bit exhausted by broken products I settled down with exactly the same error message as I reported and now I checked the Products directory on the machine I detected the problem first is clean. Thus I had described the situation on a quite clean installation regarding to "Control_Panel/Products".
Could anybody verify the problem please on probably more different installations than mine? Kind regards Andreas.
participants (3)
-
Andreas Tille -
Chris Withers -
Dieter Maurer