Bug 13163 - Duplicate records in Zebra after editing NORMARC records with DOM
Summary: Duplicate records in Zebra after editing NORMARC records with DOM
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: Main
Hardware: All All
: P5 - low critical (vote)
Assignee: Tomás Cohen Arazi
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-29 18:33 UTC by Magnus Enger
Modified: 2019-06-27 09:24 UTC (History)
1 user (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 13163: NORMARC DOM config missing <id> entry (2.61 KB, patch)
2014-10-29 18:45 UTC, Tomás Cohen Arazi
Details | Diff | Splinter Review
Bug 13163: NORMARC DOM config missing <id> entry (2.87 KB, patch)
2014-10-30 07:57 UTC, Frédéric Demians
Details | Diff | Splinter Review
Bug 13163: NORMARC DOM config missing <id> entry (3.09 KB, patch)
2014-10-30 11:03 UTC, Magnus Enger
Details | Diff | Splinter Review
[PASSED QA] Bug 13163: NORMARC DOM config missing <id> entry (3.23 KB, patch)
2014-10-31 19:39 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Magnus Enger 2014-10-29 18:33:58 UTC
With marcflavour = normarc and indexing mode = DOM, we are seeing duplication of records in Koha after editing a record. E.g. a search turns up two "copies" of the record, one old and one new. A full reindex brings things back to normal.
Comment 1 Tomás Cohen Arazi 2014-10-29 18:45:22 UTC Comment hidden (obsolete)
Comment 2 Frédéric Demians 2014-10-30 07:57:28 UTC Comment hidden (obsolete)
Comment 3 Magnus Enger 2014-10-30 11:03:11 UTC Comment hidden (obsolete)
Comment 4 Katrin Fischer 2014-10-31 19:39:19 UTC
Created attachment 33104 [details] [review]
[PASSED QA] Bug 13163: NORMARC DOM config missing <id> entry

This patch fixes the biblio-koha-indexdefs.xml for NORMARC, so
it includes the <id> element.

Because of how our DOM files work, the resulting biblio-zebra-indexdefs.xsl
for NORMARC picked the whole MARC record as ID, so every time the record
was edited, the id wouldn't match and a new record was created.

To test:
- Have a MARCXML record
- run:
  $ xsltproc etc/zebradb/marc_defs/normarc/biblios/biblio-zebra-indexdefs.xsl the_record | less
=> FAIL: verify the z:id property on the <z:record> line contains all subfields concatenated
- Apply the patch
- re-run the xsltproc line
=> SUCCESS: z:id contains the 999$c number
- Sign off :-D

Regards

Signed-off-by: Frederic Demians <f.demians@tamil.fr>

Known bug with DOM: Without <z:id> indexing biblionumber Zebra hasn't it record
unique ID, and so fails to identify existing records. Works as described. 999$c
is linked to biblionumber in default Normarc framework.

Signed-off-by: Magnus Enger <magnus@enger.priv.no>

I have applied the patch to my production server, and at least one customer has
confirmed that it fixes the problem with multiple copies of records in search
results.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script, fix matches what we have for the other MARC flavours.
Comment 5 Tomás Cohen Arazi 2014-10-31 19:45:34 UTC
Patch pushed to master.