Jason, I would be interested in seeing your script.  I wonder if your 
pingest.pl script that many people use for reingest could be extended with an 
option to trigger the maintain_901 function as another method?  Some sort of 
"trigger bib update" option?  That could handle spreading out the load/locks 
also.  Maybe that wouldn't allow the user to see the encoding errors though?

Maybe the encoding errors should be tested for a different way though, instead 
of trying to combine that with this update?

Josh Stompro - LARL IT Director

-----Original Message-----
From: Open-ils-general 
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Jason 
Sent: Thursday, April 20, 2017 7:20 AM
To: Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] Upgrading from 2.10 to 2.11 error questions

Hi, Jesse.

I won't repeat what Dan said, but I'll add that with a change to an internal 
flag or two this update will also take care of any ingests required. I think 
there's a browse or facet ingest required for 2.11.

I'm preparing to upgrade from 2.10 to 2.12, and I've run into a similar issue 
as you with the maintain_901 function and some records with "bad"
characters. I'm working on a Perl script to pull the MARC out of the database 
and do the maintain_901 work in a function in the script. The advantage of this 
is two fold:

#1 I can trap any errors that occur and output a warning message with the 
record id that causes the error so it can later be fixed.

#2 By modifying the MARC and then updating the record in the database, I can 
get the ingests to trigger without altering any database flags.

It won't be fast, but it won't have the downside of potentially locking 
significant portions of the biblio.record_entry table. Updating 1 row at a time 
should keep it at row locks, or page locks at worst.

If there is enough interest expressed on the list, I could share this code on 
github or elsewhere.


On 04/19/2017 04:22 PM, Jesse McCarty wrote:
> Hello Everyone,
> We are preparing for our spring upgrade to Evergreen, moving from 
> 2.10.3 to 2.11.3 and ran into one little bump. As part of the DB 
> upgrade, there is an update setting the 901$s for bib records. First 
> question, as seen in the attached screen shot, this threw a bunch of 
> 'no mapping found for....' Errors. Can this be safely ignored and 
> proceed with running the system after upgrading with no issues (we 
> haven't seen any issue in our testing)?
> The second, this update seem to take longer than 24 hours.  With that 
> in mind would we be able to process the entire upgrade, then use 
> Evergreen in daily production while this DB update finishes in the 
> background? Or does this need to be 100% complete before allowing 
> library's connection to the system?
> Thanks in advance,
> Jesse McCarty
> City of Burlington
> IT Technical Assistant

Reply via email to