On Tuesday 15 January 2002 05:09 pm, Jason Earl wrote:
I am glad that I am not the only one that has notice this "correct" behavior. I especially like the fact that Zope will happily roll back PostgreSQL transactions on failure. That makes combining Zope and PostgreSQL so much easier.
Yep, the first time it happened, I could hardly believe it. I was looking through the data and couldn't find the stuff that was supposed to have been inserted. The log even showed the inserts having happened, but the data just wasn't there. It finally occurred to me that zope must have notified the database and rolled everything back when it hit the error in the dtml documenteven though there was no database level error. Sure enough, there was a rollback buried in the log at the end of the request. The only caveat I have found with this behavior was again "by accident". If you are in a python script or dtml and use a try-except clause to catch an error within zope, the rollback won't happen. "Catching" the exception keeps zope from triggering the rollback machinery on the database. One solution is to rethrow the exception after you have done your own processing. We decided in one instance we really needed to catch the exception and we didn't want zope to go to the error page. So, we created a zsql method with rollback; begin; in it and then use it inside of our exception code to cause the transaction in the database to roll back. Now that I know more, a better solution probably would have been to add some logic within the standard error message that automatically forwarded the user to the page we wanted to end up on and give the user a "nice" message wthin their work environment. Anyway, suffice it to say that 99% of the time, zope, psycopg, and postgres do the "right thing" which saves a lot of time. Kudos to the respective authors. -Chris -- Chris Kratz Systems Analyst/Programmer VistaShare LLC www.vistashare.com