[OPEN-ILS-GENERAL] Upgrading from 2.10 to 2.11 error questions

[Jesse McCarty]

Jason,

Thanks for the feedback. All of our testing is done on a test system that was created from a backup of the production system and we work through the upgrades on it to work out any issues prior to upgrading the production system. With the 901 field, I am unsure how/if it is utilized within our Library or the three other libraries that are part of our system, awaiting feedback/information from the Catalogers on that one. If any of them utilize it, we'll have to figure out something that can process over a few days without causing any headaches during business hours. 

Thanks again, 

Jesse McCarty
City of Burlington
Information Systems Technician

-----Original Message-----
From: Open-ils-general [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Jason Stephenson
Sent: Wednesday, November 15, 2017 8:55 AM
To: open-ils-general at list.georgialibraries.org
Subject: Re: [OPEN-ILS-GENERAL] Upgrading from 2.10 to 2.11 error questions

Jesse,

You can skip the update to the 901 unless you plan to use the new subfield right away.

Upgrades are never as simple as one would like, particularly on a system where patches have been applied before they're released, etc.

I highly recommend having another machine where you run PostgreSQL with a copy of your production data so that you can test the upgrade scripts before doing it for real.

I also recommend becoming familiar with the build/tools/make_release script. It's used by release managers and build masters to make the release tarballs. However, with the correct options, it can be used to generate a custom DB upgrade script from any version of Evergreen to any other. I use it as a first step for our upgrades at C/W MARS.

HTH,
Jason

On 11/15/2017 11:15 AM, Jesse McCarty wrote:
> Dan,
> 
>  
> 
> Any assistance with creating a file that will break up the update task 
> would be greatly appreciated. We ended up deciding to hold off on 
> upgrading until 3.0 was released and we have a running test server 
> with semi current data in it. But, after doing all the re-ingests and 
> other associated DB upgrades throughout the various DB scripts, 
> running the update biblio.record command took something like 4 days. 
> I’m not sure how the 901 field is used within our library, but I would 
> like to ensure the upgrade is done completely so there are no 
> surprises as well as get everything ironed out in the testing 
> environment so I know exactly what to expect when we upgrade the production system to the 3.0 series.
> 
>  
> 
> Thank you again,
> 
>  
> 
> Jesse McCarty
> 
> City of Burlington
> 
> Information Systems Technician
> 
>  
> 
> *From:*Open-ils-general
> [mailto:open-ils-general-bounces at list.georgialibraries.org] *On Behalf 
> Of *Daniel Wells
> *Sent:* Wednesday, April 19, 2017 7:38 PM
> *To:* Evergreen Discussion Group
> *Subject:* Re: [OPEN-ILS-GENERAL] Upgrading from 2.10 to 2.11 error 
> questions
> 
>  
> 
> Hello Jesse,
> 
>  
> 
> For your first issue, it appears you have some kind of encoding 
> problem in some of records.  This is very common for any record with 
> foreign characters.  Without getting into too much detail, MARC 
> records are generally supposed to use UTF8 encoding (a modern, 
> universal encoding) or MARC8 encoding (an older, library-centric 
> standard).  Records will commonly say they use one encoding but have 
> characters from the other, or use characters from an entirely different, unsupported encoding (e.g.
> Latin 1).  I would recommend you try to sort these out eventually, but 
> I don't think you are doing any additional harm here.
> 
>  
> 
> For the 901s update, this update is kinda brute-force, so there is a 
> chance you will run into table lock problems if anyone else tries to 
> update the biblio.record_entry table while this is running.  The 
> biblio.record_entry table doesn't get updated during normal OPAC and 
> circ operations, so if you can avoid saving records, you should be 
> able to run it while live.  A safer option (which we typically take) 
> in situations like this is to actually generate a file where every 
> update is a separate command (UPDATE biblio.record_entry SET marc = 
> marc where id = 123; UPDATE biblio.record_entry SET marc = marc where id = 124; ...
> etc.).  Such a setup lets it plod along without holding onto multiple 
> rows as the work is done.  Let me know if you need more guidance in 
> creating such a file.
> 
>  
> 
> Also, that upgrade step comes from this feature
> addition: https://bugs.launchpad.net/evergreen/+bug/1307553 .  Unless 
> you actively plan to take advantage of this new source subfield $s, 
> you can delay this entire command until a more convenient time.  It 
> won't affect any normal operations to not have that subfield populated.
> 
>  
> 
> Sincerely,
> 
> Dan
> 
>  
> 
> On Wed, Apr 19, 2017 at 4:22 PM, Jesse McCarty 
> <jessem at burlingtonwa.gov <mailto:jessem at burlingtonwa.gov>> 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
> 
>  
> 
>  
>