Note: Do not use Master branch release/9.9.x is used as main branch
This project builds the database for 9ci software. Base on the liquibase-gradle-plugin which basically fires the commands through to the Liquibase Command Line
These are the main types of databases we build:
- Test -- for automated testing of the app.
- Development -- For demos and general human app testing.
- Seed -- This is base line db. It has settings, status codes etc that our app depends on.
the db-create script will call the tasks 'create-db', 'init-db', 'migrations'
- create-db drops and creates the database
- init-db creates the tables based on initial-state/schema.yml
- migrations creates the loadData-${env}.yml in initial-state which loads the csv data in the corresponding dir
-
./gradlew db-create
builds test on mysql -
./gradlew -DBMS=mssql db-create
builds test on sql server -
./gradlew db-create -Penv=seed
build the seed database -
./gradlew db-create -Penv=dev
build the dev database -
./gradlew -DB=fooDev db-create -Penv=dev
builds the dev db with a name of fooDev
To just run a liquibase update without a full rebuild do gradle migrations
The same flags for dbms, db and env can be used as above
./gradlew export-schema
dumps the shema.yml into the build/initial-state./gradlew export-data
dumps the loadData-$env.yml and the csv
For example to generate the seed
./gradlew export-schema export-data -Penv=seed
There are some docker scripts to light up db server to test against in the docker dir.
mysql-start
will start a mysql on default 3606
mssql-start
will light up a sql server on 1433
Project is built on circle ci. See the .circleci/config.yml file for reference.
ci-scripts/dbcreate.sh
is called during the build, which runs the migrations to load the data into database.
The script checks if it is a release branch, and if it is, it will dump the mysql database into an sql file
and then checkout the db-create-sql branch and move the mysql dump file under mysq/test_release_version.sql
(eg test_9.9.x.xql)
This db-create-sql
branch is then used by other projects to load the data into database during circleci build.
See scripts under /ci-scripts directory for reference.
TODO UPDATE THE DOCS HERE
See Liquibase Anatomy to see how the database is stored. The end of this document describes how to name your migration scripts and how to execute them.
See CookBook.groovy to see examples of migration script fragments.
Each script can have multiple changeSets. Each changeSet should consist of changes which are related to each other. Likewise each changeSet should have some relation to the named purpose of the script.
Once a script has been committed and pushed, any changeSet which has already been created should be immutable.
TODO add notes about setting to runAlways
Liquibase adds a checksum for each changeSet. If ANY change is made to that changeSet, including the nature and amount of white space, that checksum will change and all subsequent migrations to that any database which ran the original version of the changeSet will fail due to that fact.
If a script is recent and a new changeSet fits into the scheme of the script, then it's OK to add the changeSet to the end of the script. However if the script has spent more than a week or so pushed to a non-developer branch of the github repository, it should be considered off-limits and a new script file created.
To specify changeSet to be applied for specific env add context
property, value should be an environment, instead
of development
use dev
all other as is: test
, base
changeSet(id: "${clid}.1", author: "xyz", context:'dev') {}
Will be applied all changeSet
s with this context and all that has no context.
For migration plugin updates use grails dbm-update --contexts='dev'