Evergreen DokuWiki

See alsoLaunchpad Bug 1521693

# Works on most systems.  See sqitch.org for more.
$ sudo cpan App::Sqitch

Install the latest working branch from LP 1521693 using the standard DB install process. The branch is set up to use Sqitch internally. No special considerations are required for the base install.

For this example, we're cross-porting an existing SQL upgrade script for LP #1319998.

Full code is tracked in commit c999d04.

Override Sqitch DB connections parameters the sqitch flags –db-host, –db-name, –db-port, and/or –db-user. The PGPASSWORD environment variable is also honored.

$ cd Open-ILS/src/sql/schema
$ sqitch add schema.materialized_billing_summary_delete_trigger \
    --requires schema.no_delete_acq_cancel_reasons \
    -n 'Cross porting LP#1319998 schema.materialized_billing_summary_delete_trigger' 

• The –requires flag specifies which existing target our new target depends on. For consistency with existing SQL upgrades, I apply all changes sequentially, so the –requires value points to the previous Sqitch install target. Or, in other words, the last/bottom target in the sqitch.plan file.
• -n specifies a Sqitch "commit" message which appears in the Sqitch log output.

'sqitch add' adds a line to sqitch.plan to track the new install target and creates 3 new files:

deploy/schema.materialized_billing_summary_delete_trigger.sql
revert/schema.materialized_billing_summary_delete_trigger.sql
verify/schema.materialized_billing_summary_delete_trigger.sql

• The deploy/ file includes our new change. The structure of the file is practically identical to our existing upgrade/XXXX.foo.sql files, except they do not include the inline dependency check (evergreen.upgrade_deps_block_check(XXXX)).
• The revert/ file includes SQL that allows us to roll back the changes in the deploy script.
  • For example, when deploying a modified function, as is the case with this example, the revert/ file will include the original (well, previous) function definition.
• The verify/ file contains SQL to confirm the changes in the deploy/ file were properly deployed.

For example, see the contents of these 3 files at commit c999d04.

• Sanity check the status first

$ sqitch status
# On database evergreen
# Project:  evergreen
# Change:   a632d6b112c3770ad8bd3efff80b9f5700212166
# Name:     schema.no_delete_acq_cancel_reasons
# Deployed: 2015-12-29 10:28:02 -0500
# By:       Bill Erickson <berickxx@gmail.com>
# 
Undeployed change:
  * schema.materialized_billing_summary_delete_trigger

• Deploy the change

$ sqitch deploy
Deploying changes to evergreen
  + schema.materialized_billing_summary_delete_trigger .. ok

* If necessary, revert the change.

• This is particularly useful during development and testing.
• –to represents the last target that will still be deployed after the revert runs. In other words, it's the point in time you want to return to.
• In this case, I want to return to the target that occurred just before my new target/upgrade.

$ sqitch revert --to schema.no_delete_acq_cancel_reasons
Revert changes to schema.no_delete_acq_cancel_reasons from evergreen? [Yes] 
  - schema.materialized_billing_summary_delete_trigger .. ok