We'd like the ability to have the OPAC say "other people who read this, also read that." We have some very old code that does that, so I'm going to make it work with 3.4 and generally tidy it up.
Created attachment 5144 [details] [review] Bug 6772 - recommendation system This allows Koha to link similar books to provide recommendations to users. It provides a cron job that should be run regularly (daily or weekly perhaps) to build a recommendation index. When viewing books in the OPAC, those items with the closest match will be displayed. Author: Chris Cormack <chris@bigballofwax.co.nz> Author: Robin Sheat <robin@catalyst.net.nz>
Testing notes: you'll need a database with entries in old_issues, turn on the syspref (in Opac->Features->ShowRecommendations) and then run the cron job (misc/cronjobs/recommendations.pl.) This will take a fair while to run, and when it's done, viewing a record in the OPAC that's ever been borrowed will give a list of recommendations. Some points: * This will conflict with anonymising history. * It's slow to build the index. * I'd like to have it update the database as items get returned (perhaps as a queue) to allow it to not have to spend ages running a terribly long cron job. But that'll require some thought on how to approach it.
Created attachment 5250 [details] [review] Signed-off patch
It works as announced. I confirm 'recommendations' table generation is insanly slow. The result is a huge table. For a smallish 25,000 items DB, I get a recommendation table with 3,728,251 records! If 'recommendations' has to be truncated and re-created frequently, coupled with MySQL issue not releasing innodb freespace, that could conduct to disk out-of-space. Another issue is on the OPAC Recommendations tab. It shows the 100 first related books. It would be nice to have a syspref to reduce the list. I sign-off this patch, since it's disabled by default.
Yep, I agree with all your points :) I'm thinking that this is a suitable starting point, there are a lot of improvements that can be made. In particular, I'd like to build a queue of returns that have occurred, and at the end of the day just merge that with the existing index. This would make it terribly faster. Also, I'd somehow like to reduce the number of rows it puts into the database (I already halved it from the original implementation :) but I'm not quite sure how. Another thing that would be fun to do is allow it to integrate with star ratings, so 1 star counts as a negative weight, and 5 as a really positive one.
This is not as assistant QA manager that I write this. I've been thinking for long to this feature. With anonymization that is mandatory after 3 months in France, such a feature, that rebuild from scratch all associations, will mostly be useless. The only solution I see would be to have the recommendations table being filled incrementally : we run it every week, and deal only with issues of the week (linked to all readings still in old_issues/issues table) That would not be perfect (you won't connect a book issued today to a book issued 6 months ago, as it has been anonymized), but that would be much better than the actual behaviour. That would also solve the speed problem noticed by you & Frédéric Note : to avoid the DB space, the solution is to create the table with engine=myISAM As there are no constraints, that won't do any difference Marking "failed QA" as the feature as it is today is unusable. Too bad, it's something i'm dreaming of !
I'm fine with that, I'll just have to find the time to make it work incrementally.
Created attachment 17483 [details] [review] Fixing array reference bug in recommendations.pm Attached patch fixes a small reference bug in Recommendations.pm (included in the previous patch) that only occurs when we have more recommendations than the limit (default value of 100) $res = \@{ @{$res}[0..$limit] } if (@$res > $limit); will cause an error as it tries to interpret the items within $res as arrayrefs when they are hashrefs. What we really want to do is shorten our results down to never be longer than limit: $res = [ @{$res}[0..$limit] ] if (@$res > $limit);
Hi Robin and Chris, as this adds a new module I think we will need unit tests for it. Maybe also worth moving it to the Koha namespace?
(In reply to comment #9) > Hi Robin and Chris, > as this adds a new module I think we will need unit tests for it. Maybe also > worth moving it to the Koha namespace? It would need a lot more really. We're mostly leaving it here because we use it, and other people might want it too. For eligibility to Koha, it'd need a lot of work to address Frédéric and Paul's points as well. But yes, new namespace and unit tests would also be good things.
(In reply to Robin Sheat from comment #10) > It would need a lot more really. We're mostly leaving it here because we use > it, and other people might want it too. For eligibility to Koha, it'd need a > lot of work to address Frédéric and Paul's points as well. But yes, new > namespace and unit tests would also be good things. Does it mean you don't plan to work on it anymore? If so, then could you remove your name from the assigned to field?
Hello everyone, I'll put my things here since this bug seems to be about what I want to implement. I wanted to write a plugin to demonstrate the feature and bring some modularity to Koha. The code is available for review here : https://github.com/Liliputech/KohaReadSuggestion Some improvement since I posted this on the koha-devel list, it is now compatible with both MARC21 and UNIMARC and also support CSV output. Best regards, Arthur Suzuki
Just checking out this bug again... What shall we do about it? My plugin actually works the same way and it doesn't need rebase now. It also doesn't need the creation of an index. There is also this Mana patch (just added in the "See also"). Is it still worth it to keep that one opened? Is any one willing to take that one? Arthur