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

[Jason Stephenson]

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
> 
>  
> 
>  
>