On Mon, 2004-09-13 at 16:28, Alec Mitchell wrote:
On Sunday 12 September 2004 10:25 am, Chris McDonough wrote:
Note that explicit transaction control is quite dangerous in Zope if used in the normal course of operations invoked by TTW users (for reasons too obscure to go into here: see recent posts to ZODB-dev). Using it in a script is typically fine though.
Is this the case even for subtransaction commits?
Yes, subtransaction commits are actually even more dangerous in current Zopes than regular transaction commits due to an obscure bug in ZODB in all versions prior to 2.7.3. But they're really only dangerous if you (or someone using your code) inappropriately catches an exception during one of the commits. Inappropriately catching exceptions raised by a transaction commit is a pretty good way to get inconsistent app state in your database. See the ZODB-dev thread for more info. FWIW, this probably won't be solved entirely in any version of Zope 2.7, and maybe not even 2.8 (but hopefully).
I have a particular piece of code that adds a new piece of content to a CMF Site programmatically as the result of a TTW action. During the course of adding the content setId() is called on the object, which fails consistently unless a subtransaction is committed prior to the call (I believe the issue was that the created object wasn't yet stored in the ZODB, so calling setId (which causes a copy) failed).
Can you call setId on it after its attached to another persistent object instead of trying to call setId on it while it's "bare"? But.. actually, why does setId cause a copy? setId seems pretty innocuous at least in name ;-)
Is this a risky practice? If so, what's the alternative? Thanks.
Yes. See above. - C