On Saturday 10 July 2004 11:41 am, Tim Peters wrote:
[Shane Hathaway]
when the real problem is ZODB? ZODB should *not* be sensitive to the way the application handles ConflictErrors. When a ConflictError (or ReadConflictError) occurs, the transaction should fall into an "uncommitable" state. From this state, you can only abort the transaction; any attempts to write an object or commit cause another ConflictError.
AFAIK, that is the way the current releases of ZODB work. I'm not sure what "write an object" means there, though. I think I know what "commit" means. The logic in Connection.commit() raises ReadConflictError upon an attempt to commit an object that previously suffered a conflict during the transaction. How does that differ from what you want?
Here is what often happens in Zope: def setFoo(self, value): try: self.foo = value except: LOG("Oops", ERROR, "Some error happened", error=sys.exc_info()) self.change_count += 1 self.get_indexes().update(self) Some piece of code has a legitimate reason to catch but log all exceptions. Some other piece of code updates indexes. The database has now committed a partial transaction. Even worse, this can happen within the indexes, making the indexes inconsistent with themselves. Once a conflict error has occurred on any object, the rest of the transaction is on shaky grounds.
Guido doesn't agree; hoping that Python will change here is probably futile (Guido has said several times that hasattr() should never raise an exception, and that matches how it's always been documented and implemented).
That's unfortunate. Now I'm inclined to never use hasattr again. Can we petition for "hasattr2" then? :-) Shane