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.
Created attachment 32937 [details] [review] 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
Created attachment 32964 [details] [review] 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.
Created attachment 32967 [details] [review] 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.
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.
Patch pushed to master.