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.