[Zope-dev] Acquisiton, wrapping and persistence...

[Brian Lloyd]

> > Are you certain that you are not losing the acquistion context
> > on your Articles somehow? 
> 
> There's a good chance that's right :S
> Is there anything bad about storing wrapped attributes in a persistent
> object?
> Butch seemed pretty religious about unwrapping objects before 
> he stored
> them, and maybe he ain't quite wrapping them up right on the 
> way out...

At one time (Jim would know if this is still the case), the 
ZODB didn't want to store wrapped objects. Wrapping (or 
"context") is a run-time, in-memory thing while "containment" 
is a persistent thing. Wrapping really shouldn't be 
persistent, since context changes based on the way you 
_access_ things and isn't really meaningful to the 
persistent state of an object hierarchy.

When you access a subobject via getattr, the Acquisition  
machinery will ensure that the returned object is correctly 
wrapped. If you store objects under the hood in a way that 
does not go through getattr, you always need to ensure 
wrapping yourself:

class Things(Implicit):
  # Things contains individual Thing objects. They are 
  # stored as direct attributes.

  def getThing(self, id):
    # dont need to wrap, since we're going through getattr
    return getattr(self, id)

class TrickyThings:
  # TrickyThings stores its Things internally in a dict
  # and thus we don't go through getattr. So we have to 
  # do wrapping manually

  def __init__(self):
    self.things={}

  def getThing(self, id):
    # need to wrap object before returning it
    object=self.things[id]
    return object.__of__(self)


...so I'd be looking for some of this sort of trickiness 
in the code where the result is not being wrapped.


> This may be a stupid question, but why does the object need to be
> wrapped for security to work anyway?

Because security is predicated on acquisition - that is why 
you can set a permission high in the tree and allow objects 
lower in the tree to "acquire permission settings" from that 
original setting. It lets you aggregate permission settings 
down the heirarchy.

So - technically if _all_ of your permission settings were 
made directly on the object in question (i.e. all of the 
"acquire permission settings" checkboxes were unchecked 
and all appropriate permission settings were checked 
directly on that object), then it would work. But (as in 
most cases) you are using acquired settings then the 
object will have to be wrapped and have an intact 
acquisition chain at the time permissions are checked in 
order to get the result you expect.


Brian Lloyd        brian@digicool.com
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com