After upgrade, list records with missing or incorrect 901$c

This is a common cause of pain for upgrades. Let's try to identify the
problem early (even if it takes forever on a site with 3 million bibs)
and offer advice on correcting the problem if it is flagged.

Signed-off-by: Dan Scott <dscott@laurentian.ca>
Signed-off-by: Lebbeous Fogle-Weekley <lebbeous@esilibrary.com>

diff --git a/Open-ILS/src/sql/Pg/version-upgrade/2.1-2.2-upgrade-db.sql b/Open-ILS/src/sql/Pg/version-upgrade/2.1-2.2-upgrade-db.sql
index cc9b4b1..bd7b2b9 100644 (file)
--- a/Open-ILS/src/sql/Pg/version-upgrade/2.1-2.2-upgrade-db.sql
+++ b/Open-ILS/src/sql/Pg/version-upgrade/2.1-2.2-upgrade-db.sql
@@ -16198,3 +16198,22 @@ CREATE INDEX ii_poi_idx on acq.invoice_item (po_item);
 
 DROP LANGUAGE plperl;
 
+\qecho Evergreen depends heavily on each bibliographic record containing
+\qecho a 901 field with a subfield "c" to hold the record ID. The following
+\qecho query identifies the bibs that are missing 901s or whose first
+\qecho 901$c is not equal to the bib ID. This *will* take a long time in a
+\qecho big database; as the schema updates are over now, you can cancel this
+\qecho if you are in a rush.
+
+SELECT id
+  FROM biblio.record_entry
+  WHERE (
+    (XPATH('//marc:datafield[@tag="901"][1]/marc:subfield[@code="c"]/text()', marc::XML, ARRAY[ARRAY['marc', 'http://www.loc.gov/MARC21/slim']]))[1]::TEXT IS NULL
+  OR
+    (XPATH('//marc:datafield[@tag="901"][1]/marc:subfield[@code="c"]/text()', marc::XML, ARRAY[ARRAY['marc', 'http://www.loc.gov/MARC21/slim']]))[1]::TEXT <> id::TEXT)
+  AND id > -1;
+
+\qecho If there are records with missing or incorrect 901$c values, you can
+\qecho generally rely on the triggers in the biblio.record_entry table to
+\qecho populate the 901$c properly; for each offending record, run:
+\qecho   UPDATE biblio.record_entry SET marc = marc WHERE id = <id>;