Summary: | marc import not matching | ||
---|---|---|---|
Product: | Koha | Reporter: | Nicole C. Engard <nengard> |
Component: | Cataloging | Assignee: | laurenthdl <henridamien.laurent> |
Status: | CLOSED WORKSFORME | QA Contact: | Bugs List <koha-bugs> |
Severity: | critical | ||
Priority: | P3 | CC: | 1joynelson, chris, henridamien.laurent, jcamins, koha.sekjal, wizzyrea |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Attachments: |
Bug 6713, editing matching rules broken
My marc records marc files not matching data to test : ? and ! Followup proposed. |
Description
Nicole C. Engard
2011-08-11 19:51:07 UTC
Have tested in master, works for me Stage MARC Records For Import MARC Staging results : 1 records in file 0 records not staged because of MARC error 1 records staged 1 records with at least one match in catalog per matching rule "ISBN" 1 item records found and staged Stage MARC Records For Import MARC Staging results : 100 records in file 0 records not staged because of MARC error 100 records staged 81 records with at least one match in catalog per matching rule "ISBN" 0 item records found and staged So I currently can't recreate on master, will check out 3.4.x I've seen this issue on 3.05.00.004 and current HEAD, but NOT on 3.05.00.005, which indicates to me that this is not strictly a code issue, but some combination of data/Zebra indexing. I cant replicate on current head of master, or the head of 3.4.x It does feel like data Nicole, can you give me a copy of your marc file, ill try double loading it and see if that makes any difference editing the rule, even the description in admin -> matching rules breaks the rule. http://screencast.com/t/GsxcrPp60 - before rule change http://screencast.com/t/IfySIxaz - after rule change Exact same import. In the db, before edit mysql> select * from matchpoints; +------------+---------------+--------------+-------+ | matcher_id | matchpoint_id | search_index | score | +------------+---------------+--------------+-------+ | 1 | 1 | isbn | 1000 | | 2 | 2 | isbn | 1000 | +------------+---------------+--------------+-------+ after edit mysql> select * from matchpoints; +------------+---------------+--------------+-------+ | matcher_id | matchpoint_id | search_index | score | +------------+---------------+--------------+-------+ | 2 | 2 | isbn | 1000 | | 1 | 3 | isbn | 1000 | | 1 | 4 | | 0 | | 1 | 5 | | 0 | +------------+---------------+--------------+-------+ The hunt continues, it seems to be adding match checks, even when not told to Created attachment 4975 [details] [review] Bug 6713, editing matching rules broken Was a template error, but also a bug that had been in there for a while fixed too Please test by editing a matching rule, match sure no new match checks are added, and that the matchpoint components survive. Then try importing some marc records using that match rule Most of this patch is template scope changes, which are easy to read and appear quite consistent throughout. The one change in the perl script is obviously right now that I see it. Marking as Passed QA Pushed please test Created attachment 5791 [details]
My marc records
I cannot get my duplicate records to be imported .. please see attached MARC records...
mmm... I tried to add a matchpoint and feel i've reproduced a bugguy behaviour : i've just added 010a (isbn in unimarc) as matchpoint, and I get : kohacommunity>select * from matchpoints; +------------+---------------+--------------+-------+ | matcher_id | matchpoint_id | search_index | score | +------------+---------------+--------------+-------+ | 1 | 1 | isbn | 100 | | 1 | 2 | | 0 | | 1 | 3 | | 0 | +------------+---------------+--------------+-------+ aren't the id 2 & 3 buggy ? Note i've edited them and no new lines are added : portable kohacommunity>select * from matchpoints; +------------+---------------+--------------+-------+ | matcher_id | matchpoint_id | search_index | score | +------------+---------------+--------------+-------+ | 1 | 4 | isbn | 100 | | 1 | 5 | | 0 | | 1 | 6 | | 0 | +------------+---------------+--------------+-------+ Created attachment 6321 [details]
marc files not matching
I am not having luck either with importing matching bib records. See attached bib records (Little Fockers). Import rule should cause match on 024a and 245a fields. Marc file attached. Created attachment 7510 [details]
data to test : ? and !
biblio records with strings containing ! or ? are not matched.
Created attachment 7511 [details] [review] Followup proposed. To Test, use a UNIMARC Koha, and add some rule to check on Title 200$a and ISBN 010$a. Import the file http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=7510 once, index. and then try to stage the same records with that rule. The script devel/misc/testbugzillapatches.pl has detected that this bug does not apply anymore, so i'm marking this bug as "does not apply". The script is supposed to handle conflicts related to updatedatabase, but no other cases of merge conflict. So the conflict may be trivial to fix. If it happens that the patch attached does apply cleanly, please send me an email, there's something wrong in the script. It's possible, as it's a recent script. If the patch applies does not apply as I think, please rebase and resubmit, thanks Somehow I missed that I was asked for files ... do you still need my files? Looks like you've moved on and found the problem since I reported this. Sorry I missed this!! I used sandbox 3 with current master, to do a first test on the matching. I followed hdl's instructions on comment 18. I don't see problems with the matching algorithm, the results for my second import were perfect: 627 records in file 0 records not staged because of MARC error 627 records staged 627 records with at least one match in catalog per matching rule "ISBN" Not sure how to move on from here? Chris, Jared and me have tested it and couldn't reproduce the problem mentioned here. I am closing this as RESOLVED WORKSFORME. Please reopen and update the bug, if there is still a problem. |