On Thu, Jul 24, 2008 at 1:16 PM, paul POULAIN <[EMAIL PROTECTED]> wrote: > 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 => ?? I believe that running COUNT() will take just as long as running the query itself, at least that's my understanding of how COUNT() works.
Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS [EMAIL PROTECTED] |Full Demos at http://liblime.com/koha |1(888)KohaILS _______________________________________________ Koha-patches mailing list [email protected] http://lists.koha.org/mailman/listinfo/koha-patches
