Re: [Zope] Error: 'in ' requires character as left operand
Benjamin Eastwood writes:
thanks for your response! I'm still having the problem after undoing the transaction, so I'm really confused now. worse than that, I then packed the database, so no more undos... Oops. When you pack, the previous state is safed in a file called "Data.fs.old". Thus, you may go back.
However, I expect that the new role was not your problem. I suspect a new product or a newly instantiated instance of a product to be causing the problem. Then the problem would not be in your ZODB but somewhere in the code base. Maybe, you catch the exception in "AccessControl/Role.py: 106" and print out the problem causing operands. This may give a hint where the problem lies. Dieter
Hi Dieter- Wow, I love Zope more every day. I didn't know about data.fs.old, and I think that's great. We have made some progress on this. I called in the resident Python guru (he's been at it a whole week...) and we had a look at the script. We modified it with a "Try" statement as follows: for p in self.ac_inherited_permissions(1): name, value = p[:2] p=Permission(name,value,self) roles=p.getRoles(default=[]) try: d={'name': name, 'acquire': type(roles) is ListType and 'CHECKED' or '', 'roles': map( lambda ir, roles=roles, valid=valid, ip=ip: { 'name': "p%dr%d" % (ip,ir), 'checked': (valid[ir] in roles) and 'CHECKED' or '', }, indexes) } except: continue ip=ip+1 result.append(d) return result Basically trying the thing that has been hanging, but continuing on exceptions. So for every chunk of data in the database that works, it works, but if its not working, it doesn't halt the process. I still don't see the Role I created in the list for new users, but I can now get to the security screens without it hanging up on that error. We think the bogus data is still there, but we don't care about it as much. The question no becomes: What are the implications of this modification? the system works, as far as we can tell, but we are concerned that we may have hosed something up but good further down the road. Do you or anyone else out there see any potential trouble from our little hack? Thanks for all of your help! --Ben On Friday, August 23, 2002, at 10:10 AM, Dieter Maurer wrote:
Benjamin Eastwood writes:
thanks for your response! I'm still having the problem after undoing the transaction, so I'm really confused now. worse than that, I then packed the database, so no more undos... Oops. When you pack, the previous state is safed in a file called "Data.fs.old". Thus, you may go back.
However, I expect that the new role was not your problem. I suspect a new product or a newly instantiated instance of a product to be causing the problem. Then the problem would not be in your ZODB but somewhere in the code base.
Maybe, you catch the exception in "AccessControl/Role.py: 106" and print out the problem causing operands. This may give a hint where the problem lies.
Dieter
Benjamin Eastwood writes:
We have made some progress on this. I called in the resident Python guru (he's been at it a whole week...) and we had a look at the script. We modified it with a "Try" statement as follows:
for p in self.ac_inherited_permissions(1): name, value = p[:2] p=Permission(name,value,self) roles=p.getRoles(default=[]) try: d={'name': name, 'acquire': type(roles) is ListType and 'CHECKED' or '', 'roles': map( lambda ir, roles=roles, valid=valid, ip=ip: { 'name': "p%dr%d" % (ip,ir), 'checked': (valid[ir] in roles) and 'CHECKED' or '', }, indexes) } except: continue ip=ip+1 result.append(d) return result
Basically trying the thing that has been hanging, but continuing on exceptions. So for every chunk of data in the database that works, it works, but if its not working, it doesn't halt the process. I still don't see the Role I created in the list for new users, but I can now get to the security screens without it hanging up on that error. We think the bogus data is still there, but we don't care about it as much. There is a single "in" in this code fragment. It is in "valid[ir] in roles". This means, one of the "roles" is a string and not a sequence of strings (as it should be).
Add "import sys; print >> sys.stderr, roles, name" before your "continue" in the "except" clause. Then look at the output (you should run Zope in a terminal window to see the output; alternatively, you can also output into a file).
The question no becomes: What are the implications of this modification? Unrestricted "try: ... except: ..." are very bad style. They can easily hide errors that should be manifest early in the development cycle.
the system works, as far as we can tell, but we are concerned that we may have hosed something up but good further down the road. Good, that you do not yet feel well!
You should add the above print and find the true reason for this behaviour. After that, you remove the "try: ... except: ..." again. Dieter
participants (2)
-
Benjamin Eastwood -
Dieter Maurer