> > I would argue that a better plan would be to only use _v_ vars for completely > > disposable data only. The application should expect that this values will be > > gone at any random time, not just at transaction boundaries. > > I agree with this. How do we go about find code that uses the assumption that > _v_ stuff won't change unless it's at a transaction boundary?
Note that we had a problem related to this with a client recently: In CMF, skin data is stored in portal._v_skindata, and is actually needed for the whole request, but in some ZEO setting this go cleared by a get_transaction().commit(1) which was unexpected and led to breakage because in that batch treatment we used some skin methods too... We ended up calling portal.setupCurrentSkin() after the commit() to reset the skins. FYI. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] _______________________________________________ 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 )
