Hi,
----- Original Message ---- > From: Sean Owen <[email protected]> > To: [email protected] > Sent: Thursday, January 29, 2009 4:05:50 PM > Subject: Re: Taste: Clearing CachingRecommender > > 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? I'm referring to the fact that the DataModel changes first, and when it changes then the Recommender should know about that. > There is a sound logic to that of course; when data changes, that > signal starts from the DataModel and propagates from there. I suppose That's the flow and dependency I was describing. > 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. Those references make sense. It wouldn't make sense for DM to be aware of Recommender. That's why I was suggesting a generic event/listener type of system, so that any listener interested in DM changes can register and DM will call it without knowing who exactly it is calling. > 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. I think I'm confused by the direction of dependencies now, but I'll wait and see your changes next. Thanks! Otis > On Thu, Jan 29, 2009 at 6:47 PM, Otis Gospodnetic > 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 > >> 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? > > > >
