[OPEN-ILS-GENERAL] Upgrade Script for 2.6.4 to 2.7

[Ben Shum]

Mike is correct of course, and in the past several major versions
(2.5, 2.6, 2.7 at least) anyways, we've avoided issues where
backported database upgrade scripts contain any differences between
the ones used in a previous branch vs. master's version of the same
numbered scripts.  So we seem safe for now.  But as noted, it has
happened before further back in Evergreen's past and we must maintain
constant vigilance that it does not happen again to cause any
difficulties upgrading between major branches.  This is why I'm always
wary of backporting any bug fixes that contain database changes via
upgrade script.

Knowing what you're applying and testing thoroughly is the only way to
know for sure what you do to your system though, in the end.

-- Ben

On Fri, Mar 13, 2015 at 4:17 PM, Mike Rylander <mrylander at gmail.com> wrote:
> On Fri, Mar 13, 2015 at 4:00 PM, Ben Shum <bshum at biblio.org> wrote:
>>
>> Without getting into too detailed or specifics, but....
>>
>> While the numbers for upgrade scripts are purely sequential in master,
>> they are not complete and sequential for upgrades in release branches,
>> at least once you start talking maintenance releases since we do not
>> always backport every upgrade script to previous versions of
>> Evergreen.
>>
>> So if an upgrade script went 0001, 0002, 0003, etc. through release
>> 2.7.0, then we started developing for 2.8 series and the numbers
>> continued, 0004, 0005, 0006, etc. then there might be gaps where
>> things did not backport cleanly.
>>
>> So if 0005 was backported, but 0004 and 0006 was not, then the upgrade
>> scripts in 2.7 might look like 0001, 0002, 0003, 0005, while the chain
>> would remain unbroken in 2.8/master.  If you then upgraded from 2.7 to
>> 2.8, how would you know which you missed or didn't already get?  What
>> if 0005 applied a fix for something that was changed in 0004.  So if
>> you ran 0004 and not 0005 (a second time during the upgrade), your
>> system breaks with an older bad upgrade script function.
>>
>
> FWIW, if folks are reusing numbers for similar-but-different in back
> branches (as in, same effect, different code) then they're doing it wrong.
> It's happened a couple times in the past and is nothing but trouble.
>
> The rule is: every upgrade script number should be allocated in master, even
> if the script in master may be effectively empty (just a config.upgrade_log
> entry), as would be the case when the change is only needed in a back
> branch.
>
> --miker
>
>> Creating a giant version-upgrade script is how things have been done
>> to this point, but moving between major versions can still be fraught
>> with strangeness in the upgrade scripts even if you face each one on
>> its own.
>>
>> That said, we're getting better about making good upgrade scripts that
>> don't stack against each other or cause disruptions.
>>
>> I would say that this is the main reason our library system has stuck
>> to master so that we have an unbroken chain of upgrade script by the
>> numbers without any confusion of when to apply X or Y, etc.
>>
>> Perhaps not helpful, but some background thoughts to the mix.
>>
>> -- Ben
>>
>> On Fri, Mar 13, 2015 at 3:47 PM, Chris Sharp
>> <csharp at georgialibraries.org> wrote:
>> > Since that's true...
>> >
>> > Couldn't we develop some sort of upgrade mechanism that just aggregates
>> > and runs each of the constituent scripts?  What is the reasoning behind
>> > stringing them into the longer monolithic scripts since running through the
>> > numbered scripts provides the same outcome?
>> >
>> > (Asking the full list, not Galen specifically).
>> >
>> > ----- Original Message -----
>> >> From: "Galen Charlton" <gmc at esilibrary.com>
>> >> To: "Evergreen Discussion Group"
>> >> <open-ils-general at list.georgialibraries.org>
>> >> Sent: Friday, March 13, 2015 3:31:33 PM
>> >> Subject: Re: [OPEN-ILS-GENERAL] Upgrade Script for 2.6.4 to 2.7
>> >>
>> >> Hi,
>> >>
>> >> On Fri, Mar 13, 2015 at 1:51 PM, Lazar, Alexey Vladimirovich <
>> >> alexey.lazar at mnsu.edu> wrote:
>> >> >
>> >> > 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?
>> >> >
>> >>
>> >> That approach will work just fine, though checking through all of the
>> >> point
>> >> schema upgrades you plan to apply and seeing if there are any redundant
>> >> bib
>> >> reingests that you can skip can save you some time.
>> >>
>> >> Regards,
>> >>
>> >> Galen
>> >> --
>> >> Galen Charlton
>> >> Infrastructure and Added Services Manager
>> >> Equinox Software, Inc. / The Open Source Experts
>> >> email:  gmc at esilibrary.com
>> >> direct: +1 770-709-5581
>> >> cell:   +1 404-984-4366
>> >> skype:  gmcharlt
>> >> web:    http://www.esilibrary.com/
>> >> Supporting Koha and Evergreen: http://koha-community.org &
>> >> http://evergreen-ils.org
>> >>
>> >
>> > --
>> > Chris Sharp
>> > PINES System Administrator
>> > Georgia Public Library Service
>> > 1800 Century Place, Suite 150
>> > Atlanta, Georgia 30345
>> > (404) 235-7147
>> > csharp at georgialibraries.org
>> > http://pines.georgialibraries.org/
>>
>>
>>
>> --
>> Benjamin Shum
>> Evergreen Systems Manager
>> Bibliomation, Inc.
>> 24 Wooster Ave.
>> Waterbury, CT 06708
>> 203-577-4070, ext. 113
>
>



-- 
Benjamin Shum
Evergreen Systems Manager
Bibliomation, Inc.
24 Wooster Ave.
Waterbury, CT 06708
203-577-4070, ext. 113