Zope 2.4.0 CopySupport changes seem wrong
Hi there, I've just tracked down a bug that suddenly appeared with Formulator used on Zope 2.4.0. The problem is with renaming fields (which are objects in an ObjectManager). Formulator builds on ObjectManager and overrides manage_afterAdd and manage_beforeDelete to track its own list of object ids, which are kept in a certain order. Formulator offers special management facilities for this. The Field's manage_afterAdd and manage_beforeDelete pass on the id of the changed field to the order management functions of the form. It turns out however that manage_renameObject in OFS/CopySupport.py was changed, from this: self._delObject(id) ob = aq_base(ob) ob._setId(new_id) # Note - because a rename always keeps the same context, we # can just leave the ownership info unchanged. self._setObject(new_id, ob, set_owner=0) to this: b = aq_base(ob) ob._setId(new_id) # Note - because a rename always keeps the same context, we # can just leave the ownership info unchanged. self._setObject(new_id, ob, set_owner=0) self._delObject(id) Before self._delObject is moved to below ob._setId(), manage_beforeDelete receives an object as its 'item' parameter that has the changed id already. This seems wrong to me. What was the reason manage_renameObject() was changed this way? Checking CVS: [cvs.zope.org has an unfindable stylesheet today, by the way, at least with Netscape 4.7 on Linux; I got to the viewcvs interface only by turning off stylesheets in Netscape.] Hm, apparently it was an attempt to fix this collector item: http://classic.zope.org:8080/Collector/2257/view How would I implement code that removes the original id of a deleted object from say, a list of ids, in the new situation? There's no way to know now what the old id was. :) The bug report appears a big strange; it mentions an 'manage_afterDelete' which apparently doesn't exist (does the ZClass introduce this functionality?) I don't really understand how the previous functionality was wrong in the first place from this or the CVS log entry. If you're going to manage external resources with manage_beforeDelete, manage_afterAdd ought better introduce them again afterwards if you do a rename. Reordering this to make manage_afterAdd occur *before* manage_beforeDelete seems wrong to me. Regards, Martijn
On Tue, 24 Jul 2001 23:19:29 +0200, Martijn Faassen <faassen@vet.uu.nl> wrote:
I've just tracked down a bug that suddenly appeared with Formulator used on Zope 2.4.0. The problem is with renaming fields (which are objects in an ObjectManager).
Im not using 2.4 yet, but I am sure this will be a problem for me too.
Hm, apparently it was an attempt to fix this collector item:
That collector article describes a very real problem, but the solution proposed (which is now in the Zope trunk, and causes the problem Martijn discovered) is fundamentally flawed. The article describes a ZODB-hosted object which is a link to a file in the filesystem. The author wants the file deleted when the object is deleted, and not when it is renamed. A better solution to this problem involves deferring the file deletion until the end of the transaction, and only doing it if the link was not resurrected in another object. (The Collector doesnt disclose the email address of who reported it... is the original author listening? ) Toby Dickenson tdickenson@geminidataloggers.com
Toby Dickenson wrote:
The article describes a ZODB-hosted object which is a link to a file in the filesystem. The author wants the file deleted when the object is deleted, and not when it is renamed.
A better solution to this problem involves deferring the file deletion until the end of the transaction, and only doing it if the link was not resurrected in another object.
This is how ZPatterns works. This will also be very straightforward to do with the TransactionAgents product that I'm polishing up with unit tests as I type. I'll *definitely* release it before the end of today. -- Steve Alexander Software Engineer Cat-Box limited
Steve Alexander wrote:
This will also be very straightforward to do with the TransactionAgents product that I'm polishing up with unit tests as I type. I'll *definitely* release it before the end of today.
And there was much rejoicing :-) Has there been any indication from DC what it would take for this to become a core part of Zope? cheers, Chris
Chris Withers wrote:
And there was much rejoicing :-)
Has there been any indication from DC what it would take for this to become a core part of Zope?
If the ZODB transaction logic becomes "pluggable" to some degree, then TransactionAgents will just plug in there. At the moment, it is a run-time patch. Apparently, Jim Fulton was thinking of making the ZODB transaction machinery pluggable, in some sense or other. I haven't followed that up yet, as the runtime patch will suit my needs for the moment. -- Steve Alexander Software Engineer Cat-Box limited
Steve Alexander wrote:
This will also be very straightforward to do with the TransactionAgents product that I'm polishing up with unit tests as I type. I'll *definitely* release it before the end of today.
I'm growing quite fond of unit tests. I uncovered a subtle bug in the way subtransactions affect the order that agents get called. As soon as I've fixed it... :) -- Steve Alexander Software Engineer Cat-Box limited
I'm not completely sure I understand the problem (rushed for time at the moment), but it was me who f'ed up the trunk and 2.4 in order to service the collector. Can anybody provide a suggestion as to what to do in order to unbreak formulator and address the original collector issue's problem? - C Toby Dickenson wrote:
On Tue, 24 Jul 2001 23:19:29 +0200, Martijn Faassen <faassen@vet.uu.nl> wrote:
I've just tracked down a bug that suddenly appeared with Formulator used on Zope 2.4.0. The problem is with renaming fields (which are objects in an ObjectManager).
Im not using 2.4 yet, but I am sure this will be a problem for me too.
Hm, apparently it was an attempt to fix this collector item:
That collector article describes a very real problem, but the solution proposed (which is now in the Zope trunk, and causes the problem Martijn discovered) is fundamentally flawed.
The article describes a ZODB-hosted object which is a link to a file in the filesystem. The author wants the file deleted when the object is deleted, and not when it is renamed. A better solution to this problem involves deferring the file deletion until the end of the transaction, and only doing it if the link was not resurrected in another object. (The Collector doesnt disclose the email address of who reported it... is the original author listening? )
Toby Dickenson tdickenson@geminidataloggers.com
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
-- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
Hi, I have a zclass, which have a propertysheet with some properties like multiple lines, strings, etc.. which have some default values that i assigned to them. When i create an instance of that zclass and i change the value of a property, then the instance does not reflect any more the changes that i make to the zclass, which is okey. So the question is: There is a way to know using an external method or with a dtml, if an instance is different from the zclass? Thanks.. Edgardo
On Wed, 25 Jul 2001 08:16:44 -0400, Chris McDonough <chrism@digicool.com> wrote:
Can anybody provide a suggestion as to what to do in order to ... address the original collector issue's problem?
I suggest: Create a class that hooks into transaction commit; look at ZPatterns for an example of how to do this. Instances of this class will be stored as a _v_deferred_deleter attribute of his link object. manage_beforeDelete: create the _v_deferred_deleter attribnute if self doesnt have one self._v_deferred_deleter.deleted = 1 manage_afterAdd: if self has a _v_deferred_deleter attribute: self._v_deferred_deleter.deleted = 0 at transaction commit: if self._v_deferred_deleter.deleted: really delete the file remove self._v_deferred_deleter Toby Dickenson tdickenson@geminidataloggers.com
Chris McDonough wrote:
I'm not completely sure I understand the problem (rushed for time at the moment), but it was me who f'ed up the trunk and 2.4 in order to service the collector. Can anybody provide a suggestion as to what to do in order to unbreak formulator and address the original collector issue's problem?
Please reverse the patch listed here: http://lists.zope.org/pipermail/zope-checkins/2001-July/007165.html As to what the original collector issue needs... well, there have been suggestions on this list such as doing what ZPatterns does. They could also use the TransactionAgents product. However, the original collector issue should be reclassified as a Feature Request rather than a Bug Report. -- Steve Alexander Software Engineer Cat-Box limited
Formulator builds on ObjectManager and overrides manage_afterAdd and manage_beforeDelete to track its own list of object ids, which are kept in a certain order. Formulator offers special management facilities for this [...]
Hello Martijn, As far as I can see, OrderedFolder's ordering mechanism still works with 2.4. Wouldn't it be best to use it instead of your current ordering implementation? ;-) Joachim
Joachim Werner wrote:
Formulator builds on ObjectManager and overrides manage_afterAdd and manage_beforeDelete to track its own list of object ids, which are kept in a certain order. Formulator offers special management facilities for this [...]
As far as I can see, OrderedFolder's ordering mechanism still works with 2.4. Wouldn't it be best to use it instead of your current ordering implementation? ;-)
Eventually, sure, but this is a more general problem. Integrating OrderedFolder and subforms and so on takes more time to accomplish as well, and I just want to have the current formulator fixed in some way, if possible. Regards, Martijn
participants (7)
-
Chris McDonough -
Chris Withers -
Edgardo Zulian -
Joachim Werner -
Martijn Faassen -
Steve Alexander -
Toby Dickenson