Toby Dickenson wrote:
Ah-ha, that's a very elegant approach. By reusing the notional "transaction participant" interface, you didn't have to change the behavior of transactions in any way. Cool. We should definitely do it that way.On Monday 10 February 2003 8:47 pm, Shane Hathaway wrote:"tal:on-error" also catches all exceptions. It could be made to catchGreat, so there's at least 133 things to examine to see if they could catch a ConflictError. And I only wrote about 15 of those. The rest could be very time-consuming to audit.
all exceptions except ConflictError, but I don't feel like that's the
A while ago I tracked down a bug in one of our products to a case where a mutator method failed half way. It raised an exception and left the object in an invalid state. This would be safe except for a dtml-try that swallowed the exception.
Recently I have been experimenting with this attached module to ensure that an application-level object can veto a transaction. I guess it would be applicable to ConflicctErrors too.
I'm thinking the veto should be added by Connection.commit() and Connection.setstate() whenever a conflict is about to propagate. What do you think?
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce