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 <[EMAIL PROTECTED]> 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> >
_______________________________________________ Koha-patches mailing list [email protected] http://lists.koha.org/mailman/listinfo/koha-patches
