Derek Simkowiak wrote:
-> It sounds like a glitch in the DA.
Well, this is what I found. The attribute "lock" is being accessed in the _abort method, which is: -------------------------------------- def _abort(self, *ignored): try: self.db.query("ROLLBACK") self.db.store_result() finally: self.lock.release() --------------------------------------
I'd say it badly wants to be self._lock then... I dont think it matters so long as it is consistent.
Also, what is the last known *WORKING* version of the Z MySQL Database Adapter? This seems like a showstopper bug, but it's in a product that has to be pretty popular...
Did you download this from SourceForge? I dont know what Andy has been modifying of late, but I am very surprised that you're having problems with what appears to be an attribute name mismatch.
-> Alternatively, delete and recreate the DA object.
This I do not understand. How would simply deleting and re-creating an instance fix a bug in the code?
Well, I made a guess that the __init__ method would do the right thing, but the rest of the code wouldn't be able to tell that new attributes did not exist if the code had been upgraded, thus if you had OldDA which had no _lock attribute, but NewDA which did, if the code was upgraded from old to new, the DA object would be used in the new context without the new data. In those cases a delete/recreate usually cleans things up. -- Matt Kromer Zope Corporation http://www.zope.com/