[OPEN-ILS-GENERAL] Evergreen 2.9.3 - 2.10.3 upgrade issues

[Jesse McCarty]

Thanks for the information Ben,

The server in the old conversation (thanks for link!) was a 2.4.4 test server that was eventually scrapped and I did not perform the upgrade from 2.4.4. Using the old thread, as well as Galen's information, I was able to apply the fix and then the DB upgrade scripts functioned properly and I now have an upgraded and functional test server. Thank you all again!

The interesting part of this process is the two-step process in the 2.9.3-2.10.0 upgrade script where there is intervention needed to exit one screen and continue, and then the fact that part of the script takes all night and then some to finish (The server is a VM with 8 VCPUs, 18GB RAM and resides on SSD storage so it's no slouch). Even on slower hardware of previous upgrades, the records reingest process only took around 4 hours. 

Thanks again everyone!

Jesse McCarty
City of Burlington
IT Technical Assistant


-----Original Message-----
From: Open-ils-general [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Ben Shum
Sent: Thursday, June 02, 2016 4:57 PM
To: Evergreen Discussion Group <open-ils-general at list.georgialibraries.org>
Subject: Re: [OPEN-ILS-GENERAL] Evergreen 2.9.3 - 2.10.3 upgrade issues

Hi Jesse,

That error for missing metabib_field key 30 means that you do not have an entry in the table with ID of 30 (which is supposed to be LCCN in the stock installation).

Looking back in the history, I see you've mentioned some issues with this metabib_field entry before (see
http://markmail.org/message/wrdyhmaeenavxk2y)  Perhaps it would be a good idea to audit your table's entries and compare it with a stock setup to see the differences (and make adjustments).  I would start by checking to see if LCCN is already in the metabib_field table.

Something like:

SELECT id FROM config.metabib_field WHERE name = 'lccn';

If that gives you the ID for your missing LCCN field, that'll tell you what it is, instead of 30.

-- Ben

On Thu, Jun 2, 2016 at 7:18 PM, Jesse McCarty <jessem at burlingtonwa.gov> wrote:
> Thank you Galen,
>
> Looks like I have something else missing, running the 0795.schema.z39-batch-fetch-overlay.sql script came up with another error and did a ROLLBACK:
>
> ERROR:  insert or update on table "z3950_index_field_map" violates foreign key constraint "z3950_index_field_map_metabib_field_fkey" DETAIL:  Key (metabib_field)=(30) is not present in table "metabib_field".
>
> Jesse McCarty
> City of Burlington
> IT Technical Assistant
>
>
> -----Original Message-----
> From: Open-ils-general 
> [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf 
> Of Galen Charlton
> Sent: Thursday, June 02, 2016 10:03 AM
> To: Evergreen Discussion Group 
> <open-ils-general at list.georgialibraries.org>
> Subject: Re: [OPEN-ILS-GENERAL] Evergreen 2.9.3 - 2.10.3 upgrade 
> issues
>
> Hi,
>
> On Thu, Jun 2, 2016 at 12:28 PM, Jesse McCarty <jessem at burlingtonwa.gov> wrote:
>> Could simply running the 2.4.3-2.5.0-upgrade-db.sql prior to the 
>> current DB scripts work, or would only certain portions of that file 
>> need to be run? My test server is a VM with snapshots, so reverting 
>> and re-testing anything is trivial.
>
> No, a subset should suffice.  Specifically, the following steps before running the main upgrade SQL:
>
> [1] running the SQL in upgrade/0795.schema.z39-batch-fetch-overlay.sql
> (taken from the 2.10.x tarball)
>
> For example:
>
> psql> \set eg_version NULL
> psql> \i upgrade/0795.schema.z39-batch-fetch-overlay.sql
>
> [2] following up with just this bit from the 0843 upgrade:
>
> ALTER TABLE config.z3950_index_field_map DROP CONSTRAINT 
> z3950_index_field_map_metabib_field_fkey;
> ALTER TABLE config.z3950_index_field_map ADD CONSTRAINT 
> z3950_index_field_map_metabib_field_fkey FOREIGN KEY (metabib_field) 
> REFERENCES config.metabib_field(id) ON UPDATE CASCADE DEFERRABLE 
> INITIALLY DEFERRED;
>
> Apropos of a conversation during the development meeting yesterday, DB revisions 0841/0842/0843 are a good example of where backporting schema updates can be tricky.
>
> Regards,
>
> Galen
> --
> Galen Charlton
> Infrastructure and Added Services Manager Equinox Software, Inc. / 
> Open Your Library
> email:  gmc at esilibrary.com
> direct: +1 770-709-5581
> cell:   +1 404-984-4366
> skype:  gmcharlt
> web:    http://www.esilibrary.com/
> Supporting Koha and Evergreen: http://koha-community.org & 
> http://evergreen-ils.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UpgradeHistory.JPG
Type: image/jpeg
Size: 35365 bytes
Desc: UpgradeHistory.JPG
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20160613/8b56580f/attachment-0001.jpe>