At 27/11/2003 21:17, you wrote:
I added a step in my manage_addTopic() script like this to make a local reference to the "View" attrib I'm trying to acquire:
ob = Topic(...) ob.ViewAlias = self.View self._setObject(id, ob) ob = self._getOb(id)
View is a PersistentMapping, so I presume it will act like a normal mutable Python object (so when I make changes to its contents, they'll show up in the alias). I'll have to test this, anyway, to make sure, of course.
In the __setstate__ method, Topic computes using the ViewAlias which is a local attribute:
for view in self.ViewAlias.keys(): #... do some stuff with this view info pass
Is this correct? Or there is a memory leak here? In a previous post http://mail.zope.org/pipermail/zope/2002-January/107054.html Max M maxm@mxm.dk said:
If your item is subclassing persistent you should expect them to stay in the zodb. And then you should not add them to a list in your own product, but create a subclass of ObjectManager and use the _setObject() method to add the item instances.
Else your item class should not subclass persistent.
If you want to do it your way by adding item instances to a list in your product you should also be aware that every time your product is changed, or even one of the item instances, the whole object is written to the Data.fs again. Leading to a bloated Data.fs ... if you don't pack it regularly.
But doing something like that with that many objects is the wrong way to use the zodb.
From this and other sources I've been told *not* to store a Persistent object as an attribute of another object, as this would cause a memory leak. But maybe a PersistentMapping is specially crafted? I dont see anything special in its source. Perhaps the enlightened people could explain the rules to avoid memory leaks... Gabriel Genellina Softlab SRL
On Friday 28 November 2003 10:33 pm, Gabriel Genellina wrote:
At 27/11/2003 21:17, you wrote:
ob = Topic(...) ob.ViewAlias = self.View self._setObject(id, ob) ob = self._getOb(id)
Is this correct? Or there is a memory leak here? In a previous post http://mail.zope.org/pipermail/zope/2002-January/107054.html Max M maxm@mxm.dk said:
If your item is subclassing persistent you should expect them to stay in the zodb. And then you should not add them to a list in your own product, but create a subclass of ObjectManager and use the _setObject() method to add the item instances.
Else your item class should not subclass persistent.
If you want to do it your way by adding item instances to a list in your product you should also be aware that every time your product is changed, or even one of the item instances, the whole object is written to the Data.fs again. Leading to a bloated Data.fs ... if you don't pack it regularly.
But doing something like that with that many objects is the wrong way to use the zodb.
From this and other sources I've been told *not* to store a Persistent object as an attribute of another object, as this would cause a memory leak. But maybe a PersistentMapping is specially crafted? I dont see anything special in its source.
Hmm. Well, this is a little different -- storing an attribute is not the same as including the object in a list: Persistent object --(attribute)--> Persistent Object vs Persistent object --(attribute)--> Mutable List --(item)--> Persistent Object and Mutable + Non-Persistent objects are NOT supposed to be used in Persistent Objects (but you can use the _p_changed flag to do it?). The proposed solution (an Object Manager): Persistent object --(attribute)--> Persistent ObjectMgr --(attribute)--> Persistent Object suggests that the 1st case is okay. (But doesn't prove it). It's possible that I should be using "_setObject" instead of "=" to create the ViewAlias attribute. (?) Seeing as I don't really understand what the difference is.
Perhaps the enlightened people could explain the rules to avoid memory leaks...
Perhaps. I hadn't heard of this problem. I'll look out for the memory leak in case it is an issue in my case. Thanks, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
On Fri, 2003-11-28 at 20:33, Gabriel Genellina wrote:
In a previous post http://mail.zope.org/pipermail/zope/2002-January/107054.html Max M maxm@mxm.dk said:
If your item is subclassing persistent you should expect them to stay in the zodb. And then you should not add them to a list in your own product, but create a subclass of ObjectManager and use the _setObject() method to add the item instances.
From this and other sources I've been told *not* to store a Persistent object as an attribute of another object, as this would cause a memory leak.
Depends on what you mean by "memory leak" I supposed. If you *do* store persistent objects within persistent objects, you'll typically save a new copy of the parent object each time a change is made to one of the children. That can lead to some serious ZODB bloat... but then again, that's something a cron job can mostly take care of for you. To me, a memory leak is when your application allocates RAM and doesn't release it. How you store sub-objects *will* have memory usage implications, but it has little to do with persistence. For example, if you have an indexed collection of sub-objects, using a BTree for storage will be *vastly* more efficient than using a vanilla dictionary. HTH, Dylan
Dylan Reinhardt wrote at 2003-11-29 08:36 -0800:
On Fri, 2003-11-28 at 20:33, Gabriel Genellina wrote: ... If you *do* store persistent objects within persistent objects, you'll typically save a new copy of the parent object each time a change is made to one of the children.
You mean: when you do store *NON*-persistent objects within persistent objects, then ... Otherwise, any change in your Zope hierarchy would write the complete hierarchy (which, of course, is not the case) as "ObjectManager" (a persistent object) does store its content items (again persistent objects) as attributes. -- Dieter
On Sun, 2003-11-30 at 15:01, Dieter Maurer wrote:
Dylan Reinhardt wrote at 2003-11-29 08:36 -0800:
On Fri, 2003-11-28 at 20:33, Gabriel Genellina wrote: ... If you *do* store persistent objects within persistent objects, you'll typically save a new copy of the parent object each time a change is made to one of the children.
You mean: when you do store *NON*-persistent objects within persistent objects, then ...
I meant what I said, but it's quite possible I was wrong. :-)
Otherwise, any change in your Zope hierarchy would write the complete hierarchy (which, of course, is not the case) as "ObjectManager" (a persistent object) does store its content items (again persistent objects) as attributes.
But isn't that *exactly* the problem you face if you do this in a non-ObjectManager object? Any change to any part of the object necessitates saving a copy of the *whole* object. I'm under the distinct impression that ObjectManager is special in this regard and that's why it's the recommended solution for storing any non-trivial number of persistent objects. I'd greatly appreciate a correction if I've misunderstood something about that. Dylan
Dylan Reinhardt wrote at 2003-11-30 20:01 -0800:
...
You mean: when you do store *NON*-persistent objects within persistent objects, then ...
I meant what I said, but it's quite possible I was wrong. :-)
Otherwise, any change in your Zope hierarchy would write the complete hierarchy (which, of course, is not the case) as "ObjectManager" (a persistent object) does store its content items (again persistent objects) as attributes.
But isn't that *exactly* the problem you face if you do this in a non-ObjectManager object? Any change to any part of the object necessitates saving a copy of the *whole* object.
You do *NOT* face this problem when you use persistent subobjects whether they are in an ObjectManager or some other persistent object. You *DO* face this problem when the subobjects are not persistent.
I'm under the distinct impression that ObjectManager is special in this regard
This impression is not supported by the "ObjectManager" code ;-) "ObjectManager" is not special with respect to persistence...
and that's why it's the recommended solution for storing any non-trivial number of persistent objects. I'd greatly appreciate a correction if I've misunderstood something about that.
I think, I stated it already 3 times. Not sure, I can convince you. But, you may look at the "ObjectManager" code (--> "OFS/ObjectManager.py"). You will find no magic with respect to persistence. It is not even mentioned. What "ObjectManager" does: * provide creation/deletion/cloning hooks ("manage_afterAdd", "manage_beforeDelete", "manage_afterClone") * handle "ownership" and "Owner" role * "object*" methods to work with your content items You loose these services when you do not derive from "ObjectManager". But you do not loose elementary persistency behaviour. -- Dieter
Gabriel Genellina wrote at 2003-11-29 01:33 -0300:
At 27/11/2003 21:17, you wrote:
I added a step in my manage_addTopic() script like this to make a local reference to the "View" attrib I'm trying to acquire:
ob = Topic(...) ob.ViewAlias = self.View self._setObject(id, ob) ob = self._getOb(id)
View is a PersistentMapping, so I presume it will act like a normal mutable Python object (so when I make changes to its contents, they'll show up in the alias). I'll have to test this, anyway, to make sure, of course.
In the __setstate__ method, Topic computes using the ViewAlias which is a local attribute:
for view in self.ViewAlias.keys(): #... do some stuff with this view info pass
Is this correct?
This looks okay.
Or there is a memory leak here?
I do not see one (which does not necessarily mean there are none).
In a previous post http://mail.zope.org/pipermail/zope/2002-January/107054.html Max M maxm@mxm.dk said:
If your item is subclassing persistent you should expect them to stay in the zodb. And then you should not add them to a list in your own product, but create a subclass of ObjectManager and use the _setObject() method to add the item instances.
Else your item class should not subclass persistent.
I do this routinely. There is only one problem: when you change the list, you must tell the object that you did this. The problem disappears when you use a persistent object, such as a "PersistentList". Your code does not use the problematic case.
From this and other sources I've been told *not* to store a Persistent object as an attribute of another object,
Precisely, this does "ObjectManager": it stores its content items (persistent objects) as attributes of itself. As you see by this prominent example: there is not problem to do this. -- Dieter
participants (4)
-
Dieter Maurer -
Dylan Reinhardt -
Gabriel Genellina -
Terry Hancock