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

[Ben Shum]

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