"Phillip J. Eby" wrote:
This isn't necessarily a Zope bug, in the sense that it affects anything in Zope proper at the present time, to my knowledge. However, it could be under certain circumstances, and it does affect ZPublisher-based code I'm currently working on.
ZPublisher.Publish begins a transaction right before determining whether the to-be-published object is callable. If in its determination the object is *not* callable, it falls through to a return *without committing the transaction*. This makes two rather questionable assumptions: first, that the 'transaction' object can handle unbalanced begin/commit operations, and second, that the response.setBody() call (and therefore the object's asHTML() method) has no side-effects. The first may hold true for ZODB, and the second may hold true for DC-written objects, but both are probably bad assumptions for ZPublisher as a whole.
Another, similar assumption present is that the object traversal process is side-effect free and need not be part of the overall transaction. If I have a situation where an object does (for example) logging of certain sub-object accesses to a relational DB from a __bobo_traverse__ method, it will not get wrapped in a transaction, and will not be rolled back if an error occurs later. I currently work around this by using a __bobo_before__ that ensures a transaction is started, and having my transaction object ignore ZPublisher's .begin() call. Unfortunately, there is no similar workaround for the asHTML issue, since at the time of a __bobo_after__ call, there is no way to tell whether the transaction should've been committed or aborted.
May I suggest changing the relevant code (return response.setBody(object)) to:
t=response.setBody(object) if transaction: transaction.commit() return t
This would at least fix the mismatched begin/commits. Ideally, I'd like to see the transaction begun at the very beginning of the publishing traversal, but as I said, I have an existing workaround for that. Thanks.
The points you make above are entirely valid. In fact, I paid attention the first time you brought them up. ;) I took this into account when ZPublisher was reorganized some time ago (back in February). While 1.10 doesn't reflect this change, 1.11 did and 2.0 does. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.