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
http://docs.evergreen-ils.org/2.7/_mar
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 su
Hello.
On 2015-03-07, at 12:20 , Ben Shum 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 y
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
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 t
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 s
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 wrote:
> Without g
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 getting
Hi,
On Fri, Mar 13, 2015 at 3:47 PM, Chris Sharp
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 through the
> numbered scr
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
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 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 maintena
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
Hi,
On Fri, Mar 13, 2015 at 4:22 PM, Chris Sharp
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 rollback option
> (though I k
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 f
15 matches
Mail list logo