[OPEN-ILS-DEV] 1.6.0.0RC1 database update errors

[Dan Scott]

On Mon, 2009-09-14 at 16:31 -0500, Alan Rykhus wrote:
> Hello,
> 
> I had just recently installed Evergreen 1.4.0.4, had it up and running,
> but had not loaded any data into it yet. I ran the upgrade and I'm on
> the upgrade database step. I see 1 ERROR that doesn't bother me too much
> and 2 that do.

Hi Alan - all of these errors are actually expected and you should be
okay. I'll explain more below, but as an aside to the dev team perhaps
we should consider shipping database upgrade scripts written in Perl so
that we can catch expected errors rather than issuing raw SQL (which
would also be subject to an individual user's ON_ERROR_STOP preferences,
which could cause problems if ON_ERROR_STOP=yes).

> Error 1:
> 
> psql:Open-ILS/src/sql/Pg/1.4.0.5-1.6.0.0-upgrade-db.sql:3979: ERROR:
> duplicate key violates unique constraint "perm_list_code_key"
> 
> Which corresponds to:
> 
> INSERT INTO permission.perm_list (code, description) VALUES
> ('DELETE_RECORD', 'Allow a staff member to directly remove a
> bibliographic record');
> 
> Since this entry already exists, the error doesn't seem too bad.

Right, no need to worry about it.

> Errors 2 and 3:
> 
> psql:Open-ILS/src/sql/Pg/1.4.0.5-1.6.0.0-upgrade-db.sql:4044: ERROR:
> relation "auditor.action_hold_request_history" does not exist
> psql:Open-ILS/src/sql/Pg/1.4.0.5-1.6.0.0-upgrade-db.sql:4045: ERROR:
> relation "auditor.action_hold_request_history" does not exist
> 
> These correspond to:
> 
> ALTER TABLE auditor.action_hold_request_history ADD COLUMN cancel_cause
> INT;
> ALTER TABLE auditor.action_hold_request_history ADD COLUMN cancel_note
> TEXT;
> 
> These tables do not exist in the database, so this seems like an area of
> concern.

There are apparently sites that have set up auditing of extra tables,
and these lines are directed towards them. We should add at least a
comment to the script telling people not to worry about it when it
throws an error (or, if the DB upgrade was written in Perl, just catch
the error and move on without disturbing the user) - but I wonder
whether it makes sense to have the publicly available release be
internally consistent so that it doesn't throw extraneous errors.