I changed the function a bit to make it a little cleaner than the one I posted above, but I am still interested in knowing if there is a more typical way to deal with such a case.
The branch picks cleanly back through 2.0, but please remember to update the upgrade file to the 2.0 style when stamping it. I tend to forget how it goes, so here's a basic example (I think):
-SELECT evergreen.upgrade_deps_block_check('XXXX', :eg_version);
+INSERT INTO config.upgrade_log (version) VALUES ('XXXX');
Branch is pushed to http:// git.evergreen- ils.org/ ?p=working/ Evergreen. git;a=shortlog; h=refs/ heads/collab/ dbwells/ lp826844_ org_unit_ parent_ protect
I changed the function a bit to make it a little cleaner than the one I posted above, but I am still interested in knowing if there is a more typical way to deal with such a case.
The branch picks cleanly back through 2.0, but please remember to update the upgrade file to the 2.0 style when stamping it. I tend to forget how it goes, so here's a basic example (I think):
-SELECT evergreen. upgrade_ deps_block_ check(' XXXX', :eg_version);
+INSERT INTO config.upgrade_log (version) VALUES ('XXXX');
Thanks,
Dan