Lets take this back to the list.... Ive trimmed the cc list to people I think might be interested.
http://collector.zope.org/Zope/869 > I am not in line with your principle "the error report is > part of [the output of] the first transaction". The error report tells you what went wrong. You can only generate an accurate report if you see the objects in the error state. Zope is saying to your application: "your transaction is doomed. tell me why." As you said: > Drawback: you may see newer data in the error report than > has been seen by the erroneous transaction. I think thats a *major* drawback. The risk of zodb badness is a major drawback too..... Small risks add up over time. > But, even with Zope, when the error report should do > something persistently, it must do it in a new transaction > as the old state is inconsistent and can not be committed. I agree that it is unacceptable to commit changes made during the error report without starting a clean new transaction. I agree my proposal is inadequate if we need to allow this. Currently Zope doesnt allow the error report to do something persistently, and the use case for this is not obvious to me. Can you explain the use case? I am hoping that there may be a better solution that avoids the problems I raised. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson _______________________________________________ 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 )