On Wed, Nov 5, 2008 at 10:29 AM, Galen Charlton
<[EMAIL PROTECTED]>wrote:
> Hi,
>
> On Wed, Nov 5, 2008 at 5:48 AM, Paul POULAIN <[EMAIL PROTECTED]> 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
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha.org
http://lists.koha.org/mailman/listinfo/koha-devel
