-----BEGIN PGP SIGNED MESSAGE-----
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
> 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).
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
-----END PGP SIGNATURE-----
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -