On Thursday 09 October 2003 14:01, Florent Guillaume wrote:
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...
Something after the subtransaction commit must be tickling the cache garbage collector. Thats generally what subtransactions are used for.
A while ago there was a discussion on zodb-dev about _v_-like attributes that would be automatically cleared at the end of a transaction. Do we need something similar that guarantees it will _not_ be cleared until the end of the transaction?
IMO YAGNI. I think the application should tolerate the disappearance of _v_ vars. I would consider the problem with CMF skins a bug that needs to be fixed. AFAIK there is nothing stored in _v_skindata that cannot be reconstructed from data in the skins tool.
Has an issue been filed in the CMF collector regarding this?
-Casey
_______________________________________________
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 )
