Joe Atzberger a écrit : > 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. hehe... I should have think of that with my sample of "accepting patches on a stable release"... I almost got it (I asked myself the question : "it's still indexed", so speedy), but missed the fact we could get zillions of results. that proves that the more eyes are looking, the less bugs are staying alive ;-)
Note that we also have the problem with surname search : on a large library, entering "A" will return all patrons with surname starting by 'A' or firstname starting by 'A'. So, maybe we should have a 2 step check : - do the search without % - if no answer : count the number of results with %. If less than, say 100 => return, if more => ?? cheers. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08 _______________________________________________ Koha-patches mailing list [email protected] http://lists.koha.org/mailman/listinfo/koha-patches
