Object reference and the _SetObject() method
Hi, I'm playing around a bit with references to objects. I just did this: - Created a Product "Test" that adds a SimpleItem Object (with presistent, aq.implicit, rolemanager). - In a instance of "Test" I create a attribute that is a reference to another object (DTML Method). - I find that the reference survives Cut&Paste and ZODB Cache Flushes, and if I delete the original DTML Method I still can refer to it through my "Test" instance. Nothing really strange about that. My questions! Is this correct to do this or can I get my self in trouble doing direct reference in this way? What are the roll of the _SetObject() method? And that is the function of the _objects tuple? And what does the _p_changed. Thanks in advance, Johan Carlsson torped johan carlsson birkagatan 9 113 36 stockholm telefon 08-32 31 23 mobil 070-558 25 24 fax 08-32 89 47 johanc@torped.se
On Mon, 18 Oct 1999, Johan Carlsson wrote: Johan - I am not very familiar with ZODB (at least the new version) source code but here is what I remember.
My questions!
Is this correct to do this or can I get my self in trouble doing direct reference in this way?
You will eventually ;-) Especially if your objects are not Zope objects that follow the Zope management interface.
And what does the _p_changed.
setting _p_changed notifies ZODB that the relevant object has changed status and takes the neccessary steps to save it etc. You might need it in situations where changes to the object are not registered automatically by ZODB. For instance, lets suppose your object has a mutable attribute mylist, then: self.mylist.append(1) will not be registered by the ZODB, whereas: tmp=self.mylist tmp.append(1) self.mylist=tmp will be registered as ZODB intercepts the __getattr__ call. In the former case you will need to set _p_changed manually. Pavlos
My questions!
Is this correct to do this or can I get my self in trouble doing direct reference in this way? You will eventually ;-) Especially if your objects are not Zope objects that follow the Zope management interface.
But what could happen, if I keep record of the references, where could it break? And yes I'm going the link only objects with Management Interface. Here's what I whan to do: I want to create superclasses for bidirectional links between Zope objects. The link object has a object _link thats a object referense to the other object. The other objects has a list of links to it so when it's deleted it can notify the link object. Have been looking in ObjectManager if one can use the manage_beforedelete method to handle the delete through a tree.
And what does the _p_changed.
setting _p_changed notifies ZODB that the relevant object has changed status and takes the neccessary steps to save it etc. You might need it in situations where changes to the object are not registered automatically by ZODB. For instance, lets suppose your object has a mutable attribute mylist, then:
self.mylist.append(1)
will not be registered by the ZODB, whereas: tmp=self.mylist tmp.append(1) self.mylist=tmp
will be registered as ZODB intercepts the __getattr__ call.
In the former case you will need to set _p_changed manually.
I new this, but I had forgoten it. Thanks for reminding me Pavlos ;-) Johan Carlsson
At 11:50 19/10/99 , Johan Carlsson wrote:
My questions!
Is this correct to do this or can I get my self in trouble doing direct reference in this way? You will eventually ;-) Especially if your objects are not Zope objects that follow the Zope management interface.
But what could happen, if I keep record of the references, where could it break? And yes I'm going the link only objects with Management Interface.
Nothing. Just because the Zope management interface uses a hierarchical structure, doesn't mean that every object cannot be referenced more then once.
Here's what I whan to do:
I want to create superclasses for bidirectional links between Zope objects. The link object has a object _link thats a object referense to the other object. The other objects has a list of links to it so when it's deleted it can notify the link object. Have been looking in ObjectManager if one can use the manage_beforedelete method to handle the delete through a tree.
manage_beforeDelete would be the way to handle this, yes. Just remember, that other classes might also define this method. -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
At 11:50 19/10/99 , Johan Carlsson wrote:
My questions!
Is this correct to do this or can I get my self in trouble doing direct reference in this way? You will eventually ;-) Especially if your objects are not Zope objects that follow the Zope management interface.
But what could happen, if I keep record of the references, where could it break? And yes I'm going the link only objects with Management Interface. Nothing. Just because the Zope management interface uses a hierarchical structure, doesn't mean that every object cannot be referenced more then once.
Great, just what I wanted to head :-)
Here's what I whan to do:
I want to create superclasses for bidirectional links between Zope objects. The link object has a object _link thats a object referense to the other object. The other objects has a list of links to it so when it's deleted it can notify the link object. Have been looking in ObjectManager if one can use the manage_beforedelete method to handle the delete through a tree.
manage_beforeDelete would be the way to handle this, yes. Just remember, that other classes might also define this method.
Yes, I will think about it... Thanks Martijn for good advice (as always:) Johan Carlsson
On Tue, 19 Oct 1999, Martijn Pieters wrote:
Nothing. Just because the Zope management interface uses a hierarchical structure, doesn't mean that every object cannot be referenced more then once.
Thats correct. And I believe some objects are in fact referenced more than once. But be careful if you are using objects that do not conform to Zope management interface. I had one bad experience where I created a lot of instances of a custom persistent object and added them onto standard Zope objects using an external method. Later some bugs in my object source corrupted the whole ZODB. Jim Fulton pointed politely that I souldn't do such bad things, but I think he was just too polite. As it turned out you didn't have such bad thinks in mind. Pavlos
Nothing. Just because the Zope management interface uses a hierarchical structure, doesn't mean that every object cannot be referenced
more then once.
Thats correct. And I believe some objects are in fact referenced more than once. But be careful if you are using objects that do not conform to Zope management interface. I had one bad experience where I created a lot of instances of a custom persistent object and added them onto standard Zope objects using an external method. Later some bugs in my object source corrupted the whole ZODB. Jim Fulton pointed politely that I souldn't do such bad things, but I think he was just too polite.
As it turned out you didn't have such bad thinks in mind.
Thanks, I'm all excited now :-) //johan
On Tue, Oct 19, 1999 at 01:06:54PM +0200, Martijn Pieters wrote:
But what could happen, if I keep record of the references, where could it break? And yes I'm going the link only objects with Management Interface.
Nothing. Just because the Zope management interface uses a hierarchical structure, doesn't mean that every object cannot be referenced more then once.
The only thing that could happen is that if the referenced object depends on acquisition, it will break (or you reconstruct the aquisition path) Sascha -- .-> Sascha Matzke - sascha@bespin.de - http://www.bespin.de -. | Macht kaputt was euch kaputt macht... | | Ton Steine Scherben | `-- On this earth for 24 years, 6 days <----------------'
On Tue, Oct 19, 1999 at 01:06:54PM +0200, Martijn Pieters wrote:
But what could happen, if I keep record of the references, where could it break? And yes I'm going the link only objects with Management Interface.
Nothing. Just because the Zope management interface uses a hierarchical structure, doesn't mean that every object cannot be referenced more then once.
The only thing that could happen is that if the referenced object depends on acquisition, it will break (or you reconstruct the aquisition path)
Good point But I think a referenced object should be seen in the light of the new context. That's the beauty of acquisition in the first place. Have to make that work. //johanc
Johan Carlsson wrote:
My questions!
Is this correct to do this or can I get my self in trouble doing direct reference in this way? You will eventually ;-) Especially if your objects are not Zope objects that follow the Zope management interface.
But what could happen, if I keep record of the references, where could it break? And yes I'm going the link only objects with Management Interface.
Here's what I whan to do:
I want to create superclasses for bidirectional links between Zope objects. The link object has a object _link thats a object referense to the other object. The other objects has a list of links to it so when it's deleted it can notify the link object. Have been looking in ObjectManager if one can use the manage_beforedelete method to handle the delete through a tree.
This would be great! Some thoughts: - It would be really nice if ZClasses could have 'link' properties instead of objects. (ie: in propertysheets) - How about 'link-list' properties? - What if you could access the linked-to object's properties? - It would be nice if you could get ZCatalog to index on 'link' properties or objects - It would be nice if ZCatalog could index on the linked-to objects' properties - Maybe these should be called 'pointers' instead of 'links' Thoughts? Michael Bernstein.
participants (5)
-
Johan Carlsson -
Martijn Pieters -
Michael Bernstein -
Pavlos Christoforou -
Sascha Matzke