[OPEN-ILS-DEV] Testing 2.1-2.2-beta1 upgrade script

[Ben Shum]

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<bshum at biblio.org>  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