Liquibase in GDM
- Yaw Nti-Addae
First of all, we are following Liquibase's best practices.
Directory Structure
We organize our changelogs by major releases then include the major release changelogs to one master changelog file. The master changelog is the one that is ran to get the latest database changes. The initial structure is shown below:
Master Changelog
<?xml version="1.0" encoding="UTF-8"?> <databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd"> <include file="changelogs/db.changelog-1.0.xml"/> </databaseChangeLog>
Major Release Changelog
<?xml version="1.0" encoding="UTF-8"?> <databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd"> <include file="changelogs/changesets/test_changeset1.sql"/> </databaseChangeLog>
Sample Changeset
--liquibase formatted sql --changeset kpalis:test_1 context:dummy alter table variant rename column code to variant_code; --rollback alter table variant rename
SQL Formatted Changesets
Liquibase offers the ability to write changelogs on XML, SQL, YAML, JSON, etc. But we will only use SQL changelogs/changesets for manageability and consistency. Read more about the syntax here: http://www.liquibase.org/documentation/sql_format.html
Contexts
“Contexts” in Liquibase are tags you can add to changeSets to control which will be executed in any particular migration run. Any string can be used for the context name and they are checked case-insensitively.
When you run the migrator though any of the available methods, you can pass in a set of contexts to run. Only changeSets marked with the passed contexts will be run.
If you don’t assign a context to a changeSet, it will run all the time, regardless of what contexts you pass in to the migrator.
If you do not specify a context when you run the migrator, ALL contexts will be run.
Read more about contexts here: http://www.liquibase.org/documentation/contexts.html
For GOBII, we will be using the following contexts:
| Context Name | Description |
|---|---|
| Dummy | As the name implies, these are dummy changesets. They should never be ran on a non-disposable GOBII schema instance |
| General | These are changesets that apply on all GOBII instances. This means that they are not crop-specific. Majority of the changes will fall into this context. |
| <crop_name> | These are changesets that are only specific to certain crops. This will include seed data (ex. IRRI curators only need to be in the Contacts table of the IRRI GOBII instance). Context names for crop-specific instances will be the crop name, ie. rice, maize, wheat, chickpea, or sorghum. |
The contexts listed here are not final. We may find instances when we need to create more contexts, but for GOBII v1.0, these will very likely stay the same.
Property File
We will use a property file to set the liquibase target and credentials for each run. You will find this file in the $GOBII_postgres_root/builder/liquibase folder having the name liquibase.properties.
driver: org.postgresql.Driver classpath: drivers/postgresql-9.4.1209.jar url: jdbc:postgresql://localhost:5432/gobii_liquibase_test2 username: appuser password: appuser changeLogFile: changelogs/db.changelog-master.xml contexts: dev