-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Peters wrote:
> [Tres Seaver] > >>Making the attribute a persistent sub-object also eliminates the chance of a >>ConflictError based on changes to the other attributes. > > > I didn't follow that one. If other attributes change, they can > trigger conflict errors, right? Imaging object A with attributes 'foo' (a string), 'bar' (a normal Python int), and 'baz' (a hypothetical persistent int). Assigning directly to 'baz' would still conflict with assigning to 'foo' or 'bar'; however, the "persistent int" object might have an update protocol which made its value changeable without needing to rebind another PI into its parent. >>This is the use case which drives BTrees.Length, right? > > > The important part of that is its conflict resolution method, which > keeps track of the correct final size of a BTree in the face of > concurrent mutations. BTrees don't keep track of their own size > because every addition or deletion would have to percolate the change > in size back up to the root of the BTree, and we'd get conflict errors > on the root object then. As is, most additions and deletions change > only the leaf Bucket node where the mutation takes place, giving > mutation often-useful spatial locality in the face of concurrent > mutations. > > I wish we could do better than that, though: from what I see, most > people don't realize that len(some_BTree) takes time linear in the > number of elements, and sucks the entire BTree into RAM. The rest > seem to have trouble, at least at first, using BTrees.Length > correctly. I suppose that's what you get when a scheme is driven by > pragmatic implementation compromises instead of by semantic necessity. > Give enough pain, it should be possible to hide the BTrees.Length > strategy under the covers, although I'm not sure the increase in > storage size could be justified to users who have mastered the details > of doing it manually (the problem being that many uses for BTrees > never care to ask for the size, so wouldn't want to pay extra > overheads for keeping track of size efficiently). OK, cool. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCuD/M+gerLs4ltQ4RAlunAKDAXewr/rGeiG7Rhz/aWlwhmnUzDgCgpV51 n/RqyKt05uUieC93uP3Mzmw= =PX5d -----END PGP SIGNATURE----- _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )