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
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
