[Koha] Koha More regarding local call number search/barcodes

[LAURENT Henri-Damien]

Le 06/06/2011 20:57, Chris Cormack a écrit :
> On 7 June 2011 06:53, Linda Culberson <lculber at mdah.state.ms.us> wrote:
>> The problem, at least in 3.4, does exist, but changing the query from
>> sn,wrdl to sn,phr and bc,wrdl to bc,phr seems to fix it.
>>
>> But I'm still wondering if there are others - besides call numbers -
>> for which this applies.
>>
>> I apologize for the multiple emails.  I should do more research before I
>> email.  I'll try to keep quiet now.
>>
> 
> Hi Linda
> Multiple emails are fine, but perhaps this discussion is better on the
> koha-devel list.
> I think its not a new problem (i think 3.0.x up did this) but that
> doesn't mean its right.
> 
> I think phr for barcode, sn, etc makes more sense and I would
> encourage you to widen the scope of your bug to include them.
> The fix is simply changes in the template so should be relatively
> straightforward to implement and would be a welcome fix for many
> libraries I think.
> 
> Chris
Well, it all depends on what you search, but ext could be really what
you are looking for.
With phr you could look for :
AAAA/BB
And find
AAAA/BB C
AAAA/BB D
or even
C AAAA/BB
where ext would match the exact subfield...
But one default for that is that you cannot search both ext and * afaik
(could be quite easy to test if anyone interested. In a yaz-client :
f @attr 4=1 @attr 6=3 @attr 5=2 "your callnumber"
)

and that ext search requires the completeness set to 1 on the index type
you use in default.idx ... Which is commonly the case when you use p...
Moreoved, consider that using p should not replace w indexing, but be added.
Since there are places in the code or in database settings where lcn can
be searched directly without using phr modifier. And if you donot have
indexed with word... Then the search will always fail which would be
worse than the problem it fixed.
Hope that helps.
-- 
Henri-Damien LAURENT