Re: [GS/SS Beta] Gemstone and Magritte caching and classHistory

Hi, We do the following on every release. Still running 2.8 though. MCMethodDefinition cachedDefinitions removeKeys: (MCMethodDefinition cachedDefinitions keys). MCMethodDefinition shutDown. MCFileBasedRepository fastAllSubInstancesDo: [:ea | ea flushCache]. System commitTransaction. HTH

On Tue, Sep 28, 2010 at 8:59 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Hi, > > On 28.09.2010, at 19:43, Nick Ager wrote: > >> Hi, >> >> I hit a confusing bug caused by an interaction between Magritte cached descriptions and Gemstone's classHistory. >> >> I've a model component which define's it's own class side descriptionContainer: >> >> MyModel class descriptionContainer >> ^ super descriptionContainer >> componentClass: IZUIProjectEditor; >> yourself. >> >> However although I'd been changing code in IZUIProjectEditor, Magritte was holding onto an old version of my class causing unexpected problems: >> >> IZUIProjectEditor classHistory last asOop = IZProject description componentClass asOop "false" >> >> The solution I found was to flush the Magritte description cache: >> >> MADescriptionBuilder default flush >> >> >> Has anyone else had problems with updating code in Gemstone and Magritte cached descriptions? >> > This is a two-fold problem. One is that Magritte caches descriptions. So you might have to reset the magritte cache if you change a description. If you update code than you run into a gemstone specific issues. If you use a class name inside of code than you are pinpointing that piece of code to a certain class object. Updating code creates another class object that is now lookupable from the environment (Smalltalk). The compiled methods stay the same and pointing to the old class object. > >> From the Gemstone side should I worry that: >> IZUIProjectEditor classHistory size = 6 >> >> How do I go about chasing down other references to old classes within Gemstone? >> > I don't know yet but I'll investigate this. > > Norbert > > >