GetMember() cardnumber vs. firstname search
Hi, C4::Members::GetMember(), when used to look up a patron by cardnumber, retries the search on borrowers.firstname if there are no rows that have the barcode in borrowers.cardnumber. This is not exactly beautiful, and I assi,e it was inspired by some library that for whatever reason needed to overload the firstname field. Does anybody know of a reason (or a current user) why this odd fallback should be retained? Regards Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 skype: gmcharlt
Galen Charlton a écrit :
Hi, Hi,
C4::Members::GetMember(), when used to look up a patron by cardnumber, retries the search on borrowers.firstname if there are no rows that have the barcode in borrowers.cardnumber.
This is not exactly beautiful, and I assi,e it was inspired by some library that for whatever reason needed to overload the firstname field. Does anybody know of a reason (or a current user) why this odd fallback should be retained?
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. There is only one problem with that : if a patron has barcode=surname, then a search on surname returns only this patron. We have one library that recently asked us "why, when I search vita", do I get only 1 result, instead of 3 as expected, as my childrens are members of the library as well. The answer was : your cardnumber, as librarian, is vita (not a true cardnumber). "Standard" patrons have a numeric cardnumber. Not a surname. which is quite confusing, I agree. But it was the 1st time someone rised the problem. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08
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. Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 skype: gmcharlt
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
Joe Atzberger a écrit :
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 disagree ;-) It's interesting for large libraries to be able to get the result they want when they enter "doe john". As entering just "doe" would result in a large result set. So I think it's useful for large libraries, more than for small ones ;-) However, i'm not against a change here, but I just care about the useability : atm, the behaviour is quite easy for librarians (except for the cardnumber=surname case i've already pointed, but it happends only once) A can I suggest a solution where the patron would be splitted in 2 parts : cardnumber or surname : _____________________ firstname : __________________________ that would result in a better SQL, and would not be a pain for the librarian. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08
On Thu, Nov 6, 2008 at 3:57 AM, Paul POULAIN <paul.poulain@free.fr> wrote:
Joe Atzberger a écrit :
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 disagree ;-)
It's interesting for large libraries to be able to get the result they want when they enter "doe john". As entering just "doe" would result in a large result set. So I think it's useful for large libraries, more than for small ones ;-)
However, i'm not against a change here, but I just care about the useability : atm, the behaviour is quite easy for librarians (except for the cardnumber=surname case i've already pointed, but it happends only once)
A can I suggest a solution where the patron would be splitted in 2 parts : cardnumber or surname : _____________________ firstname : __________________________
that would result in a better SQL, and would not be a pain for the librarian. I think there's two points being made here:
1. (Galen and Joe): the core API shouldn't have fallbacks on what would normally appear to be a lookup on a unique value. This is primarily a coding standards statement. 2. (Paul): there should be one search box that allows search by barcode, but also falls back to searching by name (which I think most of the community would agree on). So the resolution should probably be to just split up those functions into two API calls to improve the quality of the code. Right? I happen to know for certain that a lot of libraries rely on the single search input box as the way to search for a patron record by barcode and name, and some libraries want to be able to enter in other stuff like telephone number or address in that one input box too -- they prefer not to have to click on Patrons and do an 'advanced search'. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
participants (4)
-
Galen Charlton -
Joe Atzberger -
Joshua Ferraro -
Paul POULAIN