Hi all, I have a problem that's driving me crazy. Hopefully someone here can help me sort it out. I have two products, Itinerary and Step. They are both subclasses of "Folder". I am parsing an XML-file into a DOM, using the xml.dom.minidom. The resulting DOM object is an attribute of an Itinerary instance. With the help of this DOM, I then create a hierarchy of the Itinerary and several Steps. For each DOM-element of type "Step", I create a Step in Zope. Each Step has as an attribute the node in the DOM to which it is associated. So, in the Itinerary code, I have something like this: for childNode in self.dom.childNodes: if childNode.tagName == "Step": id = 'step_%d' % len(self.objectIds()) manage_addStep(self, id, childNode) So far, so good. I get a hierarchy of Steps that expresses my DOM. But here my troubles begin. I want to add objects of type Link to the Itinerary folders, and to the Step folders. These changes should be reflected in changes in the DOM. So I have this method: def manage_addLinkAction(self, id, node=None, REQUEST=None): "Add a Link to a folder." ... self._setObject(id, Link(id, node)) linkNode = minidom.Element("Link") self.node.appendChild(linkNode) This does not give any errors. BUT: if a Link is added directly to an Itinerary, the change is reflected in the DOM, but this does not work if I add a Link to a Step. It thus seems to me that the Step actually has a copy of the node it was given as parameter when it was created, and not the original node itself. Since it's only the copy that is being manipulated by the adding of nodes, the original DOM which rests in the Itinerary object is not affected. I don't understand why this is so. It doesn't fit with how I had understood the treatment of objects as parameters in Python. Could someone please help me sort this out. If I have not given enough information, I'd be happy to supply it. TIA, Jesper -- Jesper Holmberg |"But how can | jesper.holmberg@enst-bretagne.fr | one be warm | ENST Br, BP 832, 29285 Brest, FRANCE | alone?" |
Jesper Holmberg writes:
.... This does not give any errors. BUT: if a Link is added directly to an Itinerary, the change is reflected in the DOM, but this does not work if I add a Link to a Step.
It thus seems to me that the Step actually has a copy of the node it was given as parameter when it was created, and not the original node itself. Since it's only the copy that is being manipulated by the adding of nodes, the original DOM which rests in the Itinerary object is not affected. I can well imagine that you work around Zope's persistence machinery:
I expect (though I am not sure), that Zope's persistence machinery only garantees to preserve sharing for "persistent" objects. When you share objects that do not inherit from "Persistent", I expect that the sharing may be broken and you end up with two independent copies. Dieter
* On Sat Nov 17, Dieter Maurer wrote:
When you share objects that do not inherit from "Persistent", I expect that the sharing may be broken and you end up with two independent copies.
Oh, yes that sounds reasonable. But I thought that if I made the classes Step, Itinerary and Link persistent (e.g. class Step(Folder, Persistent)), that all their attributes would be persistent as well. Am I wrong? Jesper -- Jesper Holmberg |"But how can | jesper.holmberg@enst-bretagne.fr | one be warm | ENST Br, BP 832, 29285 Brest, FRANCE | alone?" |
Jesper Holmberg writes:
* On Sat Nov 17, Dieter Maurer wrote:
When you share objects that do not inherit from "Persistent", I expect that the sharing may be broken and you end up with two independent copies.
Oh, yes that sounds reasonable. But I thought that if I made the classes Step, Itinerary and Link persistent (e.g. class Step(Folder, Persistent)), that all their attributes would be persistent as well. Am I wrong? They are persistent in the sense that they are written to ZODB (and later loaded again). However, they do not become magically full persistent objects. Especially, they do not yet OIDs which is probably necessary to preserve sharing in the ZODB.
Dieter
* On Mon Nov 19, Dieter Maurer wrote:
They are persistent in the sense that they are written to ZODB (and later loaded again). However, they do not become magically full persistent objects. Especially, they do not yet OIDs which is probably necessary to preserve sharing in the ZODB.
Ah, so if I understand you correctly, what I'm trying to do is not yet supported in Zope? I'll have to find another solution where objects are not shared? Again, thanks a lot for your help. Jesper -- Jesper Holmberg |"But how can | jesper.holmberg@enst-bretagne.fr | one be warm | ENST Br, BP 832, 29285 Brest, FRANCE | alone?" |
Hi, Am Mon, 19 Nov 2001 11:18:15 +0100 schrieb Jesper Holmberg:
* On Mon Nov 19, Dieter Maurer wrote:
They are persistent in the sense that they are written to ZODB (and later loaded again). However, they do not become magically full persistent objects. Especially, they do not yet OIDs which is probably necessary to preserve sharing in the ZODB.
Ah, so if I understand you correctly, what I'm trying to do is not yet supported in Zope? I'll have to find another solution where objects are not shared?
As far as I understood, you have to make your shared objects (the attributes) persistent by deriving them from "Persistent" so they get their own OID in the ZODB. Gruß, Markus -- You don't have to be Microsoft to suck... but it helps. (Tim Hammerquist in comp.lang.python)
participants (3)
-
Dieter Maurer -
Jesper Holmberg -
Markus Schaber