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 Seaver          +1 202-558-7113          [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to