On Wed, Jun 08, 2011 at 06:20:26PM +0530, Joe Steeve wrote:
As I mentioned on a follow-up post, we figured the 'Persistent' part. :)
On Wed, 2011-06-08 at 13:29 +0100, Laurence Rowe wrote:
My guess is that the ObjectModifiedEvent is dispatched to your object's parent and causes something to change there, with the side effect of storing your updated object.
Even if the object's parent (a btree-container) had changed, will it attempt to force-store its entire child-tree? I am trying to imagine the effect of it on a huge tree.
The smallest unit that is ever written to a ZODB is one persistent object (with all its nonpersistent attributes/items, recursively). BTrees use multiple persistent buckets for their state and are very efficient, storage-wise. But this only matters when you're adding/removing items to a BTree. If you're modifying a persistent object stored in a BTree, the BTree itself remains unmodified and does not need to be re-written Marius Gedminas -- Linux became only possible because 20 years of OS research was carefully studied, analyzed, discussed and thrown away. -- Ingo Molnar