[Koha-devel] GetMember() cardnumber vs. firstname search

[Joe Atzberger]

On Wed, Nov 5, 2008 at 10:29 AM, Galen Charlton
<galen.charlton at liblime.com>wrote:

> Hi,
>
> On Wed, Nov 5, 2008 at 5:48 AM, Paul POULAIN <paul.poulain at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20081105/877d2aad/attachment-0002.htm>