On Thu, Feb 9, 2012 at 11:35 AM, Peters, Michael <mrpet...@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.