| Summary: | Some UNIMARC item indexes could be broken whith Queryweightfields syspref | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Mathieu Saby <mathsabypro> |
| Component: | Searching | Assignee: | Mathieu Saby <mathsabypro> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P5 - low | CC: | bgkriegel, gmcharlt, jonathan.druart, vfernandes |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| Change sponsored?: | --- | Patch complexity: | Trivial patch |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
| Attachments: |
[PATCH] Bug 9830: Fix some indexes in UNIMARC item indexing
[SIGNED-OFF] Bug 9830: Fix some indexes in UNIMARC item indexing [PATCH] [SIGNED-OFF] Bug 9830: Fix some indexes in UNIMARC item indexing Bug 9830: Fix some indexes in UNIMARC item indexing |
||
|
Description
Mathieu Saby
2013-03-17 14:31:08 UTC
Created attachment 16198 [details] [review] [PATCH] Bug 9830: Fix some indexes in UNIMARC item indexing With this combinaison of sysprefs, and a UNIMARC configuration, it impossible to search on location, barcode and ccode indexes : QueryWeightFields is activated QueryAutoTruncate only if * is added But in UNIMARC, location, barcode and ccode (995 $e,$f,h) are indexed only as "words". They need to be indexed also as "phrase" Additionnaly, in UNIMARC, information about damaged and lost status of items is not indexed, while it is done in MARC21. This patch add 2 new indexes for 995$1 (damaged) and 995$3 (lost) index location, barcode and ccode as "phrase" as well as "words" indexing of items in UNIMARC could be improved. I add comments explaining the origin of Koha 995, I think it could be usefull for further changes. To test, on a UNIMARC configuration : A. indexed with GR1 1) set sysprefs QueryWeightFields as "activated" and QueryAutoTruncate as "only if * is adde" 2) select location index in advanced search and search for a value existing in your records in 995$e. 3) 0 results 4) Apply patch 5) Rebuild zebra 6) select location index in advanced search and search for a value existing in your records in 995$e. 7) x results B. indexed with DOM Do the same operations M. Saby Created attachment 21060 [details] [review] [SIGNED-OFF] Bug 9830: Fix some indexes in UNIMARC item indexing With this combinaison of sysprefs, and a UNIMARC configuration, it impossible to search on location, barcode and ccode indexes : QueryWeightFields is activated QueryAutoTruncate only if * is added But in UNIMARC, location, barcode and ccode (995 $e,$f,h) are indexed only as "words". They need to be indexed also as "phrase" Additionnaly, in UNIMARC, information about damaged and lost status of items is not indexed, while it is done in MARC21. This patch add 2 new indexes for 995$1 (damaged) and 995$3 (lost) index location, barcode and ccode as "phrase" as well as "words" indexing of items in UNIMARC could be improved. I add comments explaining the origin of Koha 995, I think it could be usefull for further changes. To test, on a UNIMARC configuration : A. indexed with GR1 1) set sysprefs QueryWeightFields as "activated" and QueryAutoTruncate as "only if * is adde" 2) select location index in advanced search and search for a value existing in your records in 995$e. 3) 0 results 4) Apply patch 5) Rebuild zebra 6) select location index in advanced search and search for a value existing in your records in 995$e. 7) x results B. indexed with DOM Do the same operations Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Work as described. No koha-qa errors Test Apply the patch Begin with GRS-1 Full reindex Search by location, no results cp files biblio-*-indexdefs.xml and record.abs to destination on etc/zebra Full reindex Search by location, got results Switch to DOM reset files Full reindex Search by location, no results cp files Full reindex Search by location, results ! I suppose it was a child's play for you to test after bug 8252 ;-) Mathieu (In reply to mathieu saby from comment #3) > I suppose it was a child's play for you to test after bug 8252 ;-) > > Mathieu Indeed! Now I'm after bug 10037 :) Bernardo This also happens for item call numbers. Besides of that, call number ordering on OPAC or Backoffice results doesn't work at all. Turning off Queryweightfields, I can search for barcodes and callnumbers in keyword searches (kw,wrdl). Turning on Queryweightfields, I get always 0 results. I've done the changes on the patch for barcodes, and I still get 0 results with Queryweightfields on and after a complete reindex. I think the problem is with QueryAutoTruncate. My last comment was incorrect. I've done the change on records.abs and xml files to add barcode:p to 995$f. Then I've done a full reindex. With Queryweightfields on and QueryAutoTruncate set to "only if * is added", a search for a barcode (example 01000039875) gives 0 results. If I put a * in the end of the search (exemple 01000039875*), I get the record with an item with the barcode. If QueryAutoTruncate is set to automatically I get also the record. With callnumbers happens the same thing. Besides of that callnumber ordering isn't working, maybe because of this problem. Vitor, I will take a look tomorrow. Note that this patch does not change the indexation of callnumbers, only barcodes, ccodes and location. M. Saby Vitor, after applying the patch, did you copy the modified files biblio-*-indexdefs.xml and record.abs to etc/zebra in your main Koha repository? I forget to mention that, but without that step it won't work. For callnumbers, if the pbm is persistant, I will try to write an other patch. Let's push this one if it is working what it is meant for. M. Saby Hi Mathieu, I didn't copy the files, but I've changed them to test barcode:w indexation. But didn't worked... Mathieu, the commit message says the patch adds 2 indexes: damaged and lost. But in fact it adds damaged and withdrawn. Could you fix the commit message please? Marked as Failed QA. Hi Jonathan, I think fixing that in the commit message when doing QA would be ok - I also tend to fix typos where I spot them :) Created attachment 21977 [details] [review] [PATCH] [SIGNED-OFF] Bug 9830: Fix some indexes in UNIMARC item indexing [typo fixed in commit message ; steps 6 and 7 added in test plan] With this combination of sysprefs, and a UNIMARC configuration, it impossible to search on location, barcode and ccode indexes : QueryWeightFields is activated QueryAutoTruncate only if * is added But in UNIMARC, location, barcode and ccode (995 $e,$f,h) are indexed only as "words". They need to be indexed also as "phrase" Additionnaly, in UNIMARC, information about damaged and withdrawn status of items is not indexed, while it is done in MARC21. This patch - add 2 new indexes for 995$1 (damaged) and 995$3 (withdrawn) - index location, barcode and ccode as "phrase" as well as "words" indexing of items in UNIMARC could be improved later. So this patch also add comments explaining the origin of Koha 995, I think it could be usefull for further changes. To test, on a UNIMARC configuration : A. indexed with GRS-1 1) set sysprefs QueryWeightFields as "activated" and QueryAutoTruncate as "only if * is added" 2) select location index in advanced search and search for a value existing in your records in 995$e => 0 results 3) Apply patch 4) Rebuild zebra 5) select location index in advanced search and search for a value existing in your records in 995$e => x results 6) mark an item as withdrawn ; search "withdrawn:1" => x results, and among them the biblio to which the item is attached 7) mark an item as damaged ; search "damaged:1" => x results, and among them the biblio to which the item is attached B. indexed with DOM Do the same operations Note : I made the test on current master. the 2 indexes damaged and withdrawn are working well (with DOM). lost index is also working well, like before. Mathieu By the way, Jonathan, the idea for this patch comes from Fridolyn (MT10271). Mathieu Created attachment 22154 [details] [review] Bug 9830: Fix some indexes in UNIMARC item indexing [typo fixed in commit message ; steps 6 and 7 added in test plan] With this combination of sysprefs, and a UNIMARC configuration, it impossible to search on location, barcode and ccode indexes : QueryWeightFields is activated QueryAutoTruncate only if * is added But in UNIMARC, location, barcode and ccode (995 $e,$f,h) are indexed only as "words". They need to be indexed also as "phrase" Additionnaly, in UNIMARC, information about damaged and withdrawn status of items is not indexed, while it is done in MARC21. This patch - add 2 new indexes for 995$1 (damaged) and 995$3 (withdrawn) - index location, barcode and ccode as "phrase" as well as "words" indexing of items in UNIMARC could be improved later. So this patch also add comments explaining the origin of Koha 995, I think it could be usefull for further changes. To test, on a UNIMARC configuration : A. indexed with GRS-1 1) set sysprefs QueryWeightFields as "activated" and QueryAutoTruncate as "only if * is added" 2) select location index in advanced search and search for a value existing in your records in 995$e => 0 results 3) Apply patch 4) Rebuild zebra 5) select location index in advanced search and search for a value existing in your records in 995$e => x results 6) mark an item as withdrawn ; search "withdrawn:1" => x results, and among them the biblio to which the item is attached 7) mark an item as damaged ; search "damaged:1" => x results, and among them the biblio to which the item is attached B. indexed with DOM Do the same operations Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Work as described. No koha-qa errors Test Apply the patch Begin with GRS-1 Full reindex Search by location, no results cp files biblio-*-indexdefs.xml and record.abs to destination on etc/zebra Full reindex Search by location, got results Switch to DOM reset files Full reindex Search by location, no results cp files Full reindex Search by location, results ! Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Pushed to master. Thanks, Mathieu! |