[OPEN-ILS-DEV] upgrade sql script

[Thomas Berezansky]

As the person who does the upgrades for the only production site  
running master that I am aware of, I avoid update_db.sh even then.  
Instead, I dump all the upgrade scripts into a single file with cat  
and manually review each of them to look for potential issues, such as  
assumptions that we are using the default permission groups or  
similar. I then commit that file to the branch I make for our update  
and run it through in a single shot.

Half the time I remove the :eg_version references and replace them  
with null then, the other half of the time I just add the command line  
option.

Thomas Berezansky
Merrimack Valley Library Consortium


Quoting Dan Scott <dan at coffeecode.net>:

> On Thu, Feb 9, 2012 at 11:35 AM, Peters, Michael
> <MRPeters at library.in.gov> wrote:
>> I could be wrong, but isn't this a job for update_db.sh?
>>
>> Something like:
>>
>> /home/opensrf/Evergreen/build/tools/update_db.sh localhost  
>> evergreen evergreen  (while in Open-ILS/src/sql/Pg)
>
> *RED ALERT* That's not a good way to try and upgrade from version to version.
>
> update_db.sh grabs the largest value from config.upgrade_log and
> applies all of the numbered updates in order after that point.
>
> The problem is that if you're currently on rel_2_1, you might have had
> upgrades # 705 and #805 backported from master to fix problems that
> also exist in rel_2_1. However, if you want to upgrade to rel_2_2,
> update_db.sh will say "Ahh, you already have everything up to #805, so
> I'll start with # 806" - even though you might really need all of #
> 706 through #804 to be applied for new features that only exist in
> rel_2_2 and master. After which - hello brokenness.
>
> update_db.sh is useful if you're a developer syncing up a test
> database to the latest version of the database schema, or a production
> site running master. Otherwise, I'd stay away.
>