On Jul 7, 2007, at 6:42 AM, Stefan H. Holek wrote:
BTrees.Length is used in many places to maintain the length of
BTrees. Just the other day it was added to
zope.app.container.btree. While I am happy about the speed
improvements, I am concerned about the fact that BTrees.Length
declares itself _p_independent. I'd like some clarification about
what happens in a conflict resolution situation, when the Length is
_p_independent but the BTree itself is not. I *think* that with
MVCC this means a read-conflict will reset the BTree, but not it's
Length.
All I could google up is this from 2004: http://mail.zope.org/
pipermail/zodb-dev/2004-April/007269.html
Now, do we need another Length class or is BTrees.Length just fine
and dandy?
Thanks for bringing this up. Looking at this again, I fail to see
the point of _p_independent in the presence of MVCC. The API was
originally added to avoid read conflicts when we read dirty data.
With MVCC we no-longer read dirty data. Unless I'm missing
something, I'd like to just drop the concept altogether.
Would you mind creating a launchpad issue to that effect?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev