On Wed, Nov 5, 2008 at 10:29 AM, Galen Charlton <galen.charlton@liblime.com>wrote:
Hi,
On Wed, Nov 5, 2008 at 5:48 AM, Paul POULAIN <paul.poulain@free.fr> wrote:
Why do you find that not beautiful ? From a perf pov, it's efficient : do an exact search, and if you don't find anything, open the search.
It is one thing for a patron search user interface to use a broad set of search critieria, but it doesn't belong in a core API whose name implies that you want to get information on one patron record. We already have SearchMember() for the staff patron search.
There is only one problem with that : if a patron has barcode=surname, then a search on surname returns only this patron.
The surname isn't involved - the code is currently searching on *first* name if it doesn't get a hit on cardnumber. I cannot see a reason, except for a one-time act of expediency in the past, why the first name field would ever be expected to have a cardnumber. However, before I remove the fallback on first name, I want to find out if some Koha user is actually depending on this.
I find the fallback to firstname entirely regrettable and have argued against it in the past. I am certain the only accounts in favor of it were regarding small libraries where a firstname basis might make sense. I agree it is bad design. We should not confuse a lookup that should be by {unique_key=>$value} with a broader search that has levels of fallback. I would say if we are doing the latter for patrons we should be using a zebra index to do it anyway, so we can get better performance and relevance ranking based on the importance of the field. --Joe