Patches item #535819, was opened at 2002-03-27 11:45 Message generated for change (Settings changed) made by jdhildeb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=535819&group_id=4866
Category: MiddleKit Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jason Hildebrand (jdhildeb) Assigned to: Chuck Esterbrook (echuck) Summary: fix dangling references in listattrs Initial Comment: Assume the following model: Class Attribute Type ------------------------------------- Item container Container name string Container name string items list of Item Now suppose there are two instances of Item (Item.1 and Item.2), one instance of container (Container.1) and both Items are contained in Container.1. That is, Item.1.container() == Item.2.container() == Container.1 (please excuse the abuse of notation). Now I do something like: c = store.fetchObject( 'Container', 1 ) items = c.items() print len(items) # should be two # delete one of the items store.deleteObject( items[0] ) store.saveChanges() print len( c.items() ) # should be one, but is still two The reason is that the Container object caches its list of Items internally as self._items, but after the Item is deleted, it doesn't know to refresh its list. So, short of calling store.clear() to toss out all cached objects (or restarting the app server), I can't convince Container.1 that it now contains only one Item. If I try to reference the "ghost" Item, I get a dangling reference error (which is correct). Is this simply a matter of MiddleKit not being complete? Or is this problem somehow unique to me? After spending a considerable amount of time going through the MK source, I suspect the former. If this is the case, I'll take a crack at implementing the correct behaviour (now that I finally grok what's going on, it doesn't seem too difficult to fix). I didn't notice this problem until recently, since I was instantiating a new store on every request (which is dumb). Now I have one global store, which is the way (I think) MiddleKit was intended to be used (although the docs don't really say much about this -- it would be good to add some of these "big picture" assumptions to the user guide). The attached patch fixes this problem. Implementation: If an object such as "Item" is deleted, it checks all objects which it references (like Container), and gets each of these objects to remove it from any list attributes they might have. ---------------------------------------------------------------------- >Comment By: Jason Hildebrand (jdhildeb) Date: 2004-03-26 17:24 Message: Logged In: YES user_id=173690 This has been fixed in CVS; this bug report is obselete. ---------------------------------------------------------------------- Comment By: Jason Hildebrand (jdhildeb) Date: 2002-09-27 12:00 Message: Logged In: YES user_id=173690 I've updated the patch against CVS head, and I added a test case to the MiddleKit test suite. Hope this helps. ---------------------------------------------------------------------- Comment By: Jason Hildebrand (jdhildeb) Date: 2002-08-29 18:44 Message: Logged In: YES user_id=173690 Hi Geoff & Chuck I don't use CVS head, which somewhat hinders my ability to test the patch, but I will check out CVS head and update the patch, and try to do a bit of testing. I'll likely do this tomorrow or Saturday morning. ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2002-08-29 15:23 Message: Logged In: YES user_id=88162 This patch unfortunately doesn't apply cleanly to Webware CVS due to changes made in the meantime. Any chance you could update it so I can patch CVS? ---------------------------------------------------------------------- Comment By: Jason Hildebrand (jdhildeb) Date: 2002-05-22 12:45 Message: Logged In: YES user_id=173690 Hi Chuck, I finally got around to optimizing this patch a bit; the logic is the same, but it now avoids pulling in any objects from the database. I also made a small optimization to the delete code which is included in this patch (more below). I think it's ready to go in. Just upgraded to 0.7 -- huge improvement in delete performance! I tested deleting a large hierarchy of objects; it took 63 seconds with 0.7b2, only 1.8 seconds with 0.7. After improving my patch it took 1.1 seconds. In an optimizing mood, I then noticed that since the results of the MiddleObject.backObjRefAttrs() function don't depend on the object itself, this function can be moved to the Klass class. This means that the calculation is only performed once per class (and then cached) instead of once per object. I've included this change in the patch, too. This further reduced my test case time to about 0.9 seconds. Not a huge improvement, but still worth it IMO, especially since it doesn't add any complexity to the code. ---------------------------------------------------------------------- Comment By: Jason Hildebrand (jdhildeb) Date: 2002-03-27 12:23 Message: Logged In: YES user_id=173690 Updated the patch. A few last minute changes to the docstrings didn't use real tabs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=535819&group_id=4866 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel