Right, a small change could affect recommendations. But wanting to see the change immediately means real-time changes, which are hard (though some people manage to pull them off, e.g. Digg now and Findory in the past).
The nice thing about events is that the dependency is one way and components up the dependency chain are not directly coupled to their dependents. I think we should ensure this remains the case in Taste. In other words, exposing some public method for refreshing the CachingRecommender and expecting something like FileDataModel to call it when FDM reloads would be bad. So, unless I'm missing something, this takes us back to before/after event hooks... but you may think of something better! :) Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Sean Owen <[email protected]> > To: [email protected] > Sent: Wednesday, January 28, 2009 4:58:26 PM > Subject: Re: Taste: Clearing CachingRecommender > > Yes, though you only need to rebuild if the file has changed of > course. I like this so I will work on the change. > > This highlights the general problem that a change of just one data > point, in theory, affects all recommendations. > > On Wed, Jan 28, 2009 at 7:33 PM, Otis Gospodnetic > wrote: > > 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?
