At least in this particular case, on-demand reloading is fine (and nicely deterministic).... although, isn't that going to be more or less the same as simply throwing away an existing CachingRecommender instance and re-creating a brand new one, starting from the newly created FileDataModel?
We have a similar situation in Solr-land. There, one can build a special index used for spellchecking. This spellcheck index reads data from the main index, so when the main index changes, it's kind of important to rebuild the spellcheck index, and this is how that's done: http://wiki.apache.org/solr/SpellCheckComponent#head-4375b11a78463f5f8b70967074d0787ea3778592 Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Sean Owen <[email protected]> > To: [email protected] > Sent: Wednesday, January 28, 2009 2:19:52 PM > Subject: Re: Taste: Clearing CachingRecommender > > ... yeah, I had hoped to avoid the complexities that come from making > this a full-fledged arbitrary dependency system and dealing with > circularities and all that. > > Perhaps to rationalize this particular situation, I can replace the > part that auto-reloads every x minutes, with a mechanism that will > reload on demand, but not more than every x minutes. I think that fits > the model better actually, and should be more efficient. > > Or is it important to get updates more quickly -- how quickly? > > On Wed, Jan 28, 2009 at 7:08 PM, Otis Gospodnetic > wrote: > > Would it be possible to create appropriate abstract methods in appropriate > classes (sorry for vagueness, I'm not yet familiar with the code enough to > suggest exact places) that would allow dependent classes to list for events > triggered/processed by classes they depend on. Here is a concrete example. > > I like how the FDM re-checks the file and re-loads it. The Recommender > depends on data read by FDM. So I would hope I could add Recommender as a > FDM > event listener. The FDM might have a method such as > addListener(FDMListener), > abstract beforeReload(...) and abstract afterReload(...). These methods > would > be called and implemented by Recommender, which could then clear its cache or > do > nothing.
