Hello.
On 2015-03-07, at 12:20 , Ben Shum bs...@biblio.org 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
Hello,
This is a reminder that early bird registration for the 2015 Evergreen
International Conference in Hood River, Oregon ends Sunday, March 15th at 11:30
pm.
After this Sunday the discounted conference rate of $200 will be increased to
$250 and will be available through May 6, 2015.
Be
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
Hi,
On Fri, Mar 13, 2015 at 3:47 PM, Chris Sharp csh...@georgialibraries.org
wrote:
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
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
Mike,
I was composing my response to Ben's message as yours came in, but it sounds
like what you're proposing below is very much in line with what I was imagining.
I'd be willing to assist in making this happen, since I think it would benefit
us all.
Thanks!
Chris
- Original Message
On Fri, Mar 13, 2015 at 4:00 PM, Ben Shum bs...@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
Hi,
On Fri, Mar 13, 2015 at 1:51 PM, Lazar, Alexey Vladimirovich
alexey.la...@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/ scripts, is there any harm in
just applying the scripts separately, in the
Chris,
That's what I've advocated for in the past (see upgrade scripts 0526 and
0537), via a helper script that 1) only applies what's needed (based on
config.upgrade_log) and 2) knows how to look up supersedes/deprecated-by
info from within the scripts. Writing down a detailed plan keeps
I should note for the mailing list that all the numbered examples I
gave were entirely fictional and meant to be representative of the
concept contained there-in, not any actual working values for any real
versions of Evergreen.
-- Ben
On Fri, Mar 13, 2015 at 4:00 PM, Ben Shum bs...@biblio.org
Thanks for the quick and detailed response, Ben.
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
Galen,
- The monolithic scripts allow for consolidating multiple point updates
into a set of statements that run more quickly. Arguably this is more of a
potential for efficiency than something that has always been taken
advantage of -- but sometimes, it has.
- Of more import, since the
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
Hi,
On Fri, Mar 13, 2015 at 4:22 PM, Chris Sharp csh...@georgialibraries.org
wrote:
Yeah, I can see the advantage of the full rollback. I wonder if the
wrapper/controller script I'm imagining (and Mike mentions in his steps to
make this actually happen response could have some sort of
Hi Gislaine,
That icon, along with several others, came with the Multi-Valued Fields
/ Composite Record Attribute definitions in 2.6. The icon is indeed
derived from fixed fields. There is some documentation on how to
configure these record attributes at
15 matches
Mail list logo
