How do I detect if an object is being deleted ? I need to detect when an object is being deleted in order to perform some clean up. The deal is (excuse the highly imaginative names) : Foo inherits from Bar which inherits from Folder Foo has a __del__ method which prints 'Foo is being deleted' When an instance of Foo is deleted (via manage_delObjects) I would expect __del__ to be called at some point but nothing happens. Am I overlooking something obvious ? Thanks Robert Leftwich (running Zope 1.10.2 on win32 NT) PS This is becoming quite urgent, so if you can help, please do so !
Robert Leftwich wrote:
How do I detect if an object is being deleted ? I need to detect when an object is being deleted in order to perform some clean up.
The deal is (excuse the highly imaginative names) :
Foo inherits from Bar which inherits from Folder Foo has a __del__ method which prints 'Foo is being deleted' When an instance of Foo is deleted (via manage_delObjects) I would expect __del__ to be called at some point but nothing happens.
Am I overlooking something obvious ?
No, you are unaware of something subtle. :) This is a good question BTW. The standard Python __del__ method is called whan an object is removed from memory. For non-persistent objects, this corresponds to the object's "death". Persistent objects may move in and out of memory many times in their lifetimes. (With ZODB3, they may have many copies in memory simultaneously.) In this case, __del__ has little to do with an object's life or it's connection to it's container. We just added a protocol for notifying an object when it is being deleted from an Object Manager (e.g. Folder): _on_delete_object() Object managers call this method just before deleting objects. This protocol is present in the publich CVS source and will be in the upcoming Zope 2 alpha release. (The current default implementation actually extends this protcol in a way that will certainly change, so don't pay attention to it.) Note that this method is *not* a destructor. It is only called when an object is removed from a collection. An object may be in multiple collections or referenced in other ways. Even if an object is only referenced in a collection, it is not removed from the database until the next pack. (When an object is removed from the database during packing, it's record is simply removed. No method gets called on the object. Old objects don't die, they just fade away. ;) Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Jim Fulton wrote:
An object may be in multiple collections or referenced in other ways. Even if an object is only referenced in a collection, it is not removed from the database until the next pack.
Somehow, I had the feeling that, while the object database allowed any containment structure, the Zope front-end itself follows a strictly arborescent model, so that *zope* objects are singly linked. Is this correct ? What is the morale of this constraint ? What about circulat references ? What will break if I use multiply linked objects ? For instance, I believe objects carry their ids, which are simultaneously their attribute name by their parent object. What zope code will break in case of object id mismatch ? If (suppose) I make sure that multiply linked objects are always stored under their unique id, by all their (therefore distinct) parents, what will break next ? How much of the problem is simply to make very sure the user can't make circular references ? Why don't objects fully acquire their id ? Or did I miss it ? Etc, etc, you know, questions are like rabbits.
(When an object is removed from the database during packing, it's record is simply removed. No method gets called on the object. Old objects don't die, they just fade away. ;)
The initial documentation mentions backwards time-travel as a supported feature of the object store. Obviously this feature competes with packing. Is there any plan to support it more fully ? Er, versions (or sessions) and undo provide some time travel, but of a rather destructive sort, what I have in mind is more like "have a peek at what it looked like a year ago and come back". My ideal would be something I would call "supertransactions", allowing daily or weekly records of "checkpoint states" to which one can come back; the "checkpoint states" themselves would be the result of the packing operation. ...this makes my mind drift to a more general question, which is not zope specific, but indeed relates to all kinds of collaborative constructions of data objects. Given the place in pure maths of what relates to the boundary between the commutative and the non-commutative, I am a bit surprised I've yet to see software give any first-rate citizen role, as a property, to the mutual commutativity of a pair of patches, in a way that reflects the wisdom of (those) mathematics. But then maybe this just reflects my current inculture, as a computer professional. On another hand, maybe I just replied to my first question ;-) Theory : "Zope only admits a singly linked arborescence because, under that model, it appears obvious that commutativity of patches can be expressed in terms of shared *spatial*areas* between states of web sites." Just kidding. Best regards, Boris Borcic -- "Modern Basic(s) carries on from his ancestor(s) the property of driving unsuspecting mindshare away from beauty"
Boris Borcic wrote:
Jim Fulton wrote:
An object may be in multiple collections or referenced in other ways. Even if an object is only referenced in a collection, it is not removed from the database until the next pack.
Somehow, I had the feeling that, while the object database allowed any containment structure, the Zope front-end itself follows a strictly arborescent model, so that *zope* objects are singly linked.
Is this correct ?
No.
What is the morale of this constraint ?
There is no such constraint. OTOH export/import (and therefore copy and paste) can get a bit strange if you export an object that references an object that lives in an unrelated part of the object hierarchy. The referenced object gets copied too, so the reference to the original referenced object is essentially broken. This is currently a problem with ZClass instances. Currently, when a ZClass instance is copied, it's class gets copied too, which is not a good thing.
What about circulat references ?
What about them? ;) Circular references do not cause memory leaks in persistent objects: - When the cache manager turns an inactive object into a "Ghost", links to other objects are broken, this eliminating circularreferences. - Packing, which accomplishes garbage collection in the database follows references from the root object and does not rely on reference counting.
What will break if I use multiply linked objects ?
Nothing, although you'll want to ponder the semantics of copy/paste (export/import).
For instance, I believe objects carry their ids, which are simultaneously their attribute name by their parent object. What zope code will break in case of object id mismatch ?
It depends on how you use ids. Certainly, an object's absolute_url method will give incorrect results if it's id is incorrect.
If (suppose) I make sure that multiply linked objects are always stored under their unique id, by all their (therefore distinct) parents, what will break next ?
Ah, I see where you are going with this. I think this should take care of it. Clearly, assumptions about how an object is used (is it managed by multiple containers) affects it's design. The places in Zope where objects are currently multiply accessed tend to be under the hood and unaffected by things like url-traversal issues.
How much of the problem is simply to make very sure the user can't make circular references ?
Well, the current user interface doesn't let them make circular references. There *is* something inherently (and very subtley) evil about circular references. Multiple references is something else. This is really the issue here and has to do with the way objects are addressed.
Why don't objects fully acquire their id ? Or did I miss it ?
Where would they acquire it from. The answer *may* be some kind of symbolic linking facility.
Etc, etc, you know, questions are like rabbits.
(When an object is removed from the database during packing, it's record is simply removed. No method gets called on the object. Old objects don't die, they just fade away. ;)
The initial documentation mentions backwards time-travel as a supported feature of the object store. Obviously this feature competes with packing.
Right. If you want complete time travel, don't pack.
Is there any plan to support it more fully ?
Yes, although they are pretty nebulous at this point.
Er, versions (or sessions) and undo provide some time travel, but of a rather destructive sort, what I have in mind is more like "have a peek at what it looked like a year ago and come back".
Right. You can do this in a brute force fashion now by setting up a site that uses the database in a read-only mode. This is alot of work though.
My ideal would be something I would call "supertransactions", allowing daily or weekly records of "checkpoint states" to which one can come back; the "checkpoint states" themselves would be the result of the packing operation.
I'm not sure why this would have anything to do with packing. You have all of the information needed sitting around in the database. There's just no good framework at higher levels to make it accessible. If you want to pursue some experiments in this area, I'd be happy to advise.
...this makes my mind drift to a more general question, which is not zope specific, but indeed relates to all kinds of collaborative constructions of data objects. Given the place in pure maths of what relates to the boundary between the commutative and the non-commutative, I am a bit surprised I've yet to see software give any first-rate citizen role, as a property, to the mutual commutativity of a pair of patches, in a way that reflects the wisdom of (those) mathematics.
You lost me. You'll have to explain this to me some time over a beer. ;)
But then maybe this just reflects my current inculture, as a computer professional.
On another hand, maybe I just replied to my first question ;-)
Theory : "Zope only admits a singly linked arborescence because, under that model, it appears obvious that commutativity of patches can be expressed in terms of shared *spatial*areas* between states of web sites."
Just kidding.
Whew. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
participants (3)
-
Boris Borcic -
Jim Fulton -
Robert Leftwich