Summary: | Is C4::Serials::GetSubscriptions searching too generally? | ||
---|---|---|---|
Product: | Koha | Reporter: | Magnus Enger <magnus> |
Component: | OPAC | Assignee: | Julian Maurice <julian.maurice> |
Status: | CLOSED FIXED | QA Contact: | Bugs List <koha-bugs> |
Severity: | minor | ||
Priority: | PATCH-Sent (DO NOT USE) | CC: | chris, fcapovilla, nengard, paul.poulain |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Attachments: | Patch from BibLibre |
Description
Magnus Enger
2011-03-14 13:58:42 UTC
Hi Magnus, we already have fixed the problem (but not submitted it upstream, our fault...) See: http://git.biblibre.com/?p=koha;a=commit;h=80ba3e785101204419922d810b7a0cd3d44c9e07 Cool, I'll just leave the bug report as it is then, so you have a bug number for your patch... ;-) Created attachment 3299 [details] [review] Patch from BibLibre Tested on current master. Pushed and merged, please test and mark resolved Works in current master. Comment on this problem : The patch that was pushed fixes this particular problem by passing less filters to the GetSubscriptions() subroutine, but it doesn't fix the main problem : GetSubscriptions() is still searching too generally. I tried printing the final query created by GetSubscriptions and here is what it looks like : SELECT subscription.*, subscriptionhistory.*, biblio.title,biblioitems.issn,biblio.biblionumber FROM subscription LEFT JOIN subscriptionhistory USING(subscriptionid) LEFT JOIN biblio ON biblio.biblionumber = subscription.biblionumber LEFT JOIN biblioitems ON biblio.biblionumber = biblioitems.biblionumber WHERE biblio.biblionumber=? AND (biblio.title LIKE ? ) OR (subscription.callnumber LIKE ? ) OR (subscription.location LIKE ? ) OR (subscription.notes LIKE ? ) OR (subscription.internalnotes LIKE ? ) AND (biblioitems.issn LIKE ? ) OR (subscription.callnumber LIKE ? ) ORDER BY title Example binds used : "47569" "%M%" "%M%" "%M%" "%M%" "%M%" "%1715-4820%" "%1715-4820%" I think the query generated by GetSubscriptions needs to be fixed too... The fix does what it intended to do: when you want to find a subscription from biblionumber, it's an "exact" search. The other parameter is for a kind of "approximative" search. Should it search on callnumber or not ? on title or not ? with % or not ? I think it's another debate. Our libraries usually don't complain when there is a little bit too many results, they understand that the search is "large". A fix could be to have the search explicitely done on "title", "callnumber", ... But that would require the user form to have more fields available (atm, there is only one field). I' not sure i've an opinion wether it's a good idea or not. Here is the comment of this subroutine : this function gets all subscriptions which have title like $title,ISSN like $ISSN and biblionumber like $biblionumber. With this description, I thought that the subroutines would return all subscriptions with the specified title AND ISSN AND biblionumber. Right now, it doesn't exactly returns that because the ANDs and ORs of the query are all mixed together without useful parentheses. If I'm not wrong, with MySQL's operator precedences, the current query looks like this : (biblio.biblionumber=? AND biblio.title LIKE ? ) OR subscription.callnumber LIKE ? OR subscription.location LIKE ? OR subscription.notes LIKE ? OR (subscription.internalnotes LIKE ? AND biblioitems.issn LIKE ? ) OR subscription.callnumber LIKE ? I think it was meant to be like this : (biblio.biblionumber=?) AND (biblio.title LIKE ? OR subscription.callnumber LIKE ? OR subscription.location LIKE ? OR subscription.notes LIKE ? OR subscription.internalnotes LIKE ?) AND (biblioitems.issn LIKE ? OR subscription.callnumber LIKE ?) I understand that the current fix does solve the problem, but I just want to bring to someone's attention that the GetSubscriptions subroutine might not work as intended. |