Hi Phillip, Is there a good reason that ExternalAttributeProvider sets up a dictionary to put its attributes into, rather than a PersistentMapping? This is the way it seems to store things in the Rack: Rack's BTree | + object_id : PersistentMapping | + ('ZPatterns.Rack', 'Self') : Persistent object, eg ZClass instance + ('ZPatterns.AttributeProviders','ExternalAttributes') : {} # dict filled with external attributes The thing is that when the dict gets updated by the External Attribute Provider, the whole second-level-in PersistentMapping object gets updated. If an External Attribute Provider instead set up a new PersistentMapping in its slot, only that PersistentMapping would change in the ZODB on updates. Do you think this is a reasonable change for the External Attribute Provider class? Or, should I write my own provider, derived from External Attribute Provider, that uses a PersistentMapping instead of a dict? Actually, I can see the use for a Persistent AttributeProvider where you have a configurable slot, so you can group attributes that change at different rates in groups of those that change together. The second half of the slot-key's tuple would be configurable as a property on the attribute provider. -- Steve Alexander Software Engineer Cat-Box limited