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 <[email protected]>:
On Thu, Feb 9, 2012 at 11:35 AM, Peters, Michael
<[email protected]> 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.
