Hello. On 2015-03-07, at 12:20 , Ben Shum <[email protected]> wrote:
> So the upgrade scripts are intended to be done sequentially as written > due to certain limitations in the build process of Evergreen currently > (this is still under community discussion). So unfortunately, if > you're already on 2.6.4, then you may have some small edits necessary > to perform the upgrade from 2.6 series to 2.7 series. If I recall > correctly, you should be able to the run the 2.6.3-2.7 script without > problems, but when you try to do the 2.7.0-2.7.1 script, it might > cause conflicts because some of the changes in the 2.7.0-2.7.1 might > already have been done during the 2.6.3-2.6.4 script. Looking at the same situation, but with a 2.5.4 to 2.6.0 upgrade. (2.5.4+all announced security patches applied, that is). > In situations like these, most system administrators will manually > compare the differences between the conflicting upgrade scripts and > make edits to the files as necessary to "skip" anything that's already > been done and doesn't need to be re-done. Since an Open-ILS/src/sql/Pg/version-upgrade script is a subset of several specific Open-ILS/src/sql/Pg/upgrade/XXXX scripts, is there any harm in just applying the XXXX scripts separately, in the order they appear, to get the database up to a certain “version" number? > Long-term, the developer community needs to complete discussions about > how to make the database upgrade process cleaner between major version > shifts, but this is the present reality. Following up on my previous statement, could it help towards a cleaner solution if the version-upgrade scripts were “virtual” scripts that do not actually include the XXXX code, but call the XXXX scripts externally, with statements wrapped in IF EXISTS clauses probably? Thanks. Aleksey Lazar IS Developer and Integrator - PALS http://www.mnpals.org/
