Sounds like you want one-way dependencies which I agree with, largely for simplicity. That's how it works now. The Recommender does not depend on the DataModel, but the other way around. Or are you in fact arguing for the other way around?
There is a sound logic to that of course; when data changes, that signal starts from the DataModel and propagates from there. I suppose I'd done it the other way just because that was the order in which the components depend on each other to produce recommendations. A Recommender has a reference to a DataModel and not the other way around. One last interesting factor is that in some cases (particularly slope-one) it is possible to very quickly take into account a single preference change without recomputing everything. This is why Recommender has setPreference(); ultimately that calls to DataModel.setPreference() but along the way perhaps the Recommender can do better than simply clearing a cache. All this said I am not convinced it wouldn't be better to completely turn around the dependencies here. I'd like to make a small change to FileDataModel now, per this thread, and then mull it over a little bit since I'd want to think through the implications a bit. It's medium-sized surgery on the code. On Thu, Jan 29, 2009 at 6:47 PM, Otis Gospodnetic <[email protected]> wrote: > 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? > >
