[ZODB-Dev] BTrees and Mutables, was Re: [IndexedCatalog] bug in default indexing

[Christian Reis]

Crossposting to ZODB-dev to try and get the Wizards<tm>' help!

On Tue, Feb 11, 2003 at 02:12:10PM -0500, Nicholas Henke wrote:
> Is it possible that the index._p_changed in index_item is not telling
> index which is a Btree derivative that index[value] has changed. Would
> it make more sense to set index[value]._p_changed = 1 instead, or in
> conjunction with index._p_changed = 1?

I've had a look at these issues in the past and my limited understanding
*is* the following:

    - BTrees themselves are mutable objects. However, since they are
      first-class Python instances, and because they have "magic"
      properties, there is no requirement to set _p_changed=1 with holding
      a reference to a changed BTree. I.E.:

        tree = BTree()
        obj.tree = tree
        tree['foo'] = 'foo'
        # obj has _p_changed set *magically*

    At least this is what I understand from
    http://www.zope.org/Members/ajung/BTrees/FrontPage 

    Am I wrong?

    - If a BTree holds a reference to a non-BTree *mutable* type such as
      a list, and that list changes, then the *BTree itself* needs to
      have _p_changed set. I.E.:

        # Continuing from the above example, with obj.tree = tree
        tree['bar'] = [1,2,3]
        tree['bar'].append(4)
        tree._p_changed = 1

    Now my question is, really, this: does obj, who holds the BTree
    reference, also require _p_changed to be set, or does the BTree's
    magic notify the ZODB that obj needs to be saved, too? IOW:

        # Do we also need this?
        obj._p_changed = 1 

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL