Evergreen DokuWiki

See alsoLaunchpad Bug 1521693

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

1. Install the latest working branch from LP 1521693 and use the standard DB install tools.
2. Alternatively, you can create a database manually with the working branch checked out like so:

$ cd Open-ILS/src/sql/schema
# Change DB connections parameters to suit your environment.
$ sudo -u postgres psql --set db_name=evergreen -f tools/create_database_extensions.sql

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