[OPEN-ILS-DEV] A Proposal for Improving Functional DB Upgrades

[Bill Erickson]

+1 to hackaway discussion.

I'll get some thoughts out while they are on my mind...

Regarding functions that change signatures, I'm curious how we'd handle
cases where (for example) a view references a function whose signature
changes.  Something like this?

BEGIN;
DROP VIEW V;
\i /path/to/functions/foo.sql; -- load new function def.
CREATE VIEW V (...);
COMMIT;

Something else to consider.. Maintaining one copy of each function will (I
believe) require the full implementation of the supersedes/deprecates
functionality.  If, for example, a function's signature changes multiple
times across a series of SQL schema upgrades, the intermediate upgrades
will have to be marked as deprecated since the version of the function they
reference will not be accessible, having been replaced by the newer
version.

-b


On Mon, Oct 31, 2016 at 12:37 PM, Galen Charlton <gmc at esilibrary.com> wrote:

> Hi,
>
> On Fri, Oct 28, 2016 at 12:17 PM, Dan Wells <dbw2 at calvin.edu> wrote:
> > I know it would take a little massaging to get our dependency ducks in a
> > row, but it is certainly doable and I think it would be worth it.
> >
> > What say you all?
>
> I think it's a good idea and worth discussing at the hack-a-way, so
> I've taken the liberty of adding it to the agenda.
>
> I think it would be useful to retain some sort of version stamp, but
> that can be readily handled via a conditional insert into
> config.upgrade_log at the top of the functions script.  I also note
> that it will necessarily accumulate 'DROP FUNCTION IF EXISTS'
> statements over time, as stored functions either disappear or change
> signature, but that doesn't strike me as a big deal.
>
> Regards,
>
> Galen
> --
> Galen Charlton
> Infrastructure and Added Services Manager
> Equinox Software, Inc. / Open Your Library
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20161031/6431ac31/attachment.html>