Bug 4340 - patron name search does not handle punctuated names
Summary: patron name search does not handle punctuated names
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Guillaume Hatt
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks: 6253
  Show dependency treegraph
 
Reported: 2010-03-24 03:23 UTC by D Ruth Holloway
Modified: 2013-12-05 20:01 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Patch as sent to koha-patches (2.89 KB, patch)
2010-03-24 16:13 UTC, Chris Cormack
Details | Diff | Splinter Review
Patch minus a typo (2.95 KB, patch)
2010-03-24 16:39 UTC, Chris Cormack
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:26:01 UTC


---- Reported by dbavousett@ptfs.com 2010-03-24 15:23:05 ----

In C4::Members::SearchMember, the system is searching for surnames like "string%" or "% string%".  Thus, for a search "steuben", you'll get Steuben, Steubenstein, or Von Steuben, but not "D'Steuben" or "Smith-Steuben".

One of our customers would like this to work to find these punctuated names correctly, but merely using LIKE "%string%" is not the answer; in a search for "van", you want to find "Smith-Vandenberg" "Van Smith" or "Vanilla", but not "Sullivan".  

mysql has the capability of doing REGEXP there, but it is very, very slow, but I found a resource describing a method of using a more-general LIKE, then REGEXPing that, which testing indicates is *much* faster than adding a bunch of LIKEs for all the combinations.

Patch coming shortly.



---- Additional Comments From dbavousett@ptfs.com 2010-03-24 16:13:33 ----

Created an attachment
Patch as sent to koha-patches





---- Additional Comments From dbavousett@ptfs.com 2010-03-24 16:39:57 ----

Created an attachment
Patch minus a typo





--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:26 UTC  ---

This bug was previously known as _bug_ 4340 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4340
Imported an attachment (id=2024)
Imported an attachment (id=2025)

Actual time not defined. Setting to 0.0
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
CC member jwagner@ptfs.com does not have an account here
The original submitter of attachment 2024 [details] [review] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 2025 [details] [review] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.

Comment 1 Owen Leonard 2010-06-29 17:14:41 UTC
Currently the system is successfully returning results for the example here which was failing: A search for "steuben" will return patrons named "Smith-Steuben". However, the system also shows the less desirable behavior described: a search for "van" will return "Sullivan."

I'm tempted to mark this bug fixed since a punctuated name can be searched for successfully. Or should the scope of the bug be changed so that we're talking specifically about the refined LIKE search described above?
Comment 2 D Ruth Holloway 2010-08-13 14:59:40 UTC
This patch *works*, but it's a pact with the Devil.  Once you get a large number of patrons in the database, it's astonishingly inefficient, and thus slows down searches for patrons in an unacceptable way.
Comment 3 Nicole C. Engard 2011-03-07 18:28:29 UTC
Does that mean we should not even test this patch but find a better way to do it?
Comment 4 Chris Cormack 2011-04-08 02:12:27 UTC
Pushed, please test