[Koha-patches] [PATCH] BUG-2393: ENHANCEMENT: SearchMember() uses "cardnumber%" wildcard - if other search-types fail

[Joe Atzberger]

This is a bad idea for any sizable library.  Consider a converted Dynix
library or any using the common 14-digit Codabar format identifiers.  All
patron barcodes would be "2" + 4 digit institution code + 9 more digits
(typically 8 incremental, 1 checksum).  A truncated search would return ALL
patrons for anything less than 6 digits.

Let the librarian ask for a truncated search with a "%", and they can have
it.  Otherwise, what we really want is a zebra index with liberal rules
about truncation, not an SQL query that intentionally steps through 50,000
patrons with 13 (or more!) LIKE clauses.

There is no limit on the SearchMember query, and expansions of scope on a
common operation like this will have predictable detrimental effects on
performance.  While most SearchMember's problems predate this patch, I think
this is a step in the wrong direction.

--joe


On Wed, Jul 23, 2008 at 10:55 PM, Mason James <mason.loves.sushi at gmail.com>
wrote:

> ---
>  C4/Members.pm |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/C4/Members.pm b/C4/Members.pm
> index d1546d9..3b64ad2 100644
> --- a/C4/Members.pm
> +++ b/C4/Members.pm
> @@ -228,7 +228,7 @@ JOIN borrower_attribute_types USING (code)
>  WHERE staff_searchable = 1
>  AND attribute like ?
>  )";
> -            push (@bind, $searchstring);
> +            push (@bind, "$searchstring%");
>         }
>         $query .= "order by $orderby";
>
> --
> 1.5.5.GIT <http://lists.koha.org/mailman/listinfo/koha-patches>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-patches/attachments/20080724/970a3fdc/attachment-0002.htm>