I've come up with an answer which I will be using, as its simple and good enough.
I will now have: Article - int Id; - string Body; - int[] Cache_LikedBy; <--- new .. (User and Like models remain the same). When adding a Like, I will add the user's id to the Cache_LikedBy array. I will ensure the values are sorted to allow for binary sort. For storage, it will actually just be a comma separated list in a TEXT/ VARCHAR column in the database. This will bring no loss to performance (no extra joins), will allow me to determine quickly if a given user has Liked an Article (check for their User Id in the cache), and also let me still keep extra info (like the date the user Liked the Article) in the separate Like object which I can look at should it be necessary. It is also much simpler than trying to dynamically join/set a 'CurrentUserLike' value. Thought I'd post an answer in case this helps anyone else. Regards, Andrew On Jul 18, 8:25 pm, Andrew Armstrong <[email protected]> wrote: > Hello, > > I have a domain model like: > > Model > --------- > > Article > - int Id; > - string Body; > .. > > User > - int Id; > - string Name; > > Like > - int Id; > - Article Article; > - User User; > > Use Case > --------------- > > 1) Many users can individually 'Like' as many Article's as they like > > 2) I want the "You liked this" status reflected on each Article, when > viewing a list of 100+ Article's at once (more than one, anyway) > > Problem > ------------ > > I am unsure how to optimize, as well as actually fetch the information > needed, to determine whether the Current User logged into the site has > a Like object associated with them and each of the 100+ Article's they > happen to be viewing on the same page at once. > > I feel I can do this with a LEFT JOIN and HQL by ensuring each > Criteria query I ever write relating to Article's always requests this > information, but I want to avoid writing the same HQL statement's > multiple times any time I attempt to access an Article list/instance. > > I want this automatic without needing to be patched in at every > necessary point. > > Solutions so far > ----------------------- > > I am using Fluent NHibernate, and have investigated using a Filter, or > Where clause, but they don't seem to be dynamic (ie, to let me grab > the current logged in User at the time of the query being prepared). > > I feel like I want a solution like this in the web scenario: > > class ArticleMap : ClassMap<Article> > { > .... > > References(x => x.CurrentUserLike).Where("CurrentUserLike.User.Id > = :currentUserId").Add("currentUserId", > HackyGlobalState.GetCurrentUserId()); > .... > > } > > I don't really want that; but that's how I feel I want it working. > > Then consumers of the Article objects simply check if > article.CurrentUserLike != null to determine if the current user has > "Liked" that Article previously. > > -- > > Does anyone have any ideas? Am I going about this the wrong way? I'd > like to of course have clean code to support this feature, so am weary > of having to violate DRY and make sure every 'Article' query I ever > perform requests the right user's Like instance as a separate join > etc, which also sounds terribly manual and laborus. > > Ideas and technical know-how appreciated. > > Thanks, > Andrew -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
