So I skipped over the drop language command and now hit my next snag:
psql:Evergreen/Open-ILS/src/sql/Pg/version-upgrade/2.1-2.2-upgrade-db.sql:15516:
ERROR: malformed JSON string, neither array, object, number, string or
atom, at character offset 0 (before "(end of string)") at line 20.
CONTEXT: PL/Perl function "materialize_holding_code"
Any ideas on that one, looks serials related?
-- Ben
On 4/5/12 8:25 AM, Dan Scott wrote:
On Thu, Apr 5, 2012 at 7:16 AM, Ben Shum<[email protected]> wrote:
It seemed to be going well till I hit this and the rest of the script died
out:
psql:Evergreen/Open-ILS/src/sql/Pg/version-upgrade/2.1-2.2-upgrade-db.sql:15328:
ERROR: cannot drop language plperl because other objects depend on it
DETAIL: function migration_tools.add_codabar_checkdigit(text) depends on
language plperl
function migration_tools.expand_barcode(text,text,integer,text,text) depends
on language plperl
HINT: Use DROP ... CASCADE to drop the dependent objects too.
So I suppose that I have to figure out which other custom functions (I think
that one is an ESI migration_tools one?) exist that utilize plperl and
change those before I can drop plperl from our Evergreen database.
I hit that overnight as well, and would recommend that we move the
DROP LANGUAGE statement outside of the transaction so that it doesn't
roll back all of the other work.
It seems likely that many sites will have added custom plperl
functions over the past few years and will hit this roadblock after
what can be a very long upgrade script (somewhere in the vicinity of
6-8 hours for us on our testing server), which in turn slows down the
testing& adoption process.
--
Benjamin Shum
Open Source Software Coordinator
Bibliomation, Inc.
32 Crest Road
Middlebury, CT 06762
203-577-4070, ext. 113
