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 _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )