On this page:

22.2smileutil: Migrate Database

 

The migrate-database command migrates a Smile CDR database to the latest version.

A typical Smile CDR installation will have two sets of tables:

  • The Cluster Manager tables (contains configuration, audit events, etc.)
  • The FHIR Storage tables (contains FHIR data)

In the default Smile CDR configuration, both the Cluster Manager and the FHIR Storage tables are placed in the same database schema. It is possible to configure Smile CDR to use different schemas/users for each, or even to have multiple separate schemas. The examples below assume the default configuration.

The following example shows the command in action:

# Migrate the Cluster Manager
bin/smileutil migrate-database --driver POSTGRES_9_4 --mode CLUSTERMGR --url "jdbc:postgresql://localhost/cdr" --username MYUSER --password MYPASS

# Migrate the Persistence Module
bin/smileutil migrate-database --driver POSTGRES_9_4 --mode PERSISTENCE --url "jdbc:postgresql://localhost/cdr" --username MYUSER --password MYPASS

22.2.1Options

 
  • -d [driver] (or --driver [driver]) – This argument tells the tool which database dialect to use. The values used here are identical to the values used in the Smile CDR configuration properties file.
  • -n [username] (or --username [username]) – The database username.
  • -p [password] (or --password [password]) – The database password.
  • -u [url] (or --url [url]) – The JDBC database URL.
  • -m [mode] (or --mode [mode]) – Specifies whether the cluster manager (CLUSTERMGR) or FHIR Storage (PERSISTENCE) module tables should be migrated, or both (CLUSTERMGR_AND_PERSISTENCE). In a typical Smile CDR installation these tables will both exist in the same database schema, so this command may be run once for each or by using the combined option. Some installations may separate these into separate schemas, or may not have FHIR Storage tables at all.
  • -r (or --dry-run) – (optional) If included, instructs smileutil to perform a dry run, where no changes are made.
  • --dont-use-flyway – If set, disabled Flyway based migration (see below).
  • --out-of-order-permitted – If set, allow migration tasks to be run out of order (see below).

Note that many of the options above require an argument from a list of possible values (such as the Database Driver and the Smile CDR Version. You can see a list of possible options by using the following command:

bin/smileutil help migrate-database

22.2.2Examples

 

Migrating the default H2 database setup:

bin/smileutil migrate-database -d H2_EMBEDDED -u "jdbc:h2:file:./h2_database/h2_clustermgr;create=true" --username "SA" --password "SA" -f V2019_11 -t V2020_02 -m CLUSTERMGR_AND_PERSISTENCE  -r

22.2.3Disabling Flyway

 

If you are deploying to an old/unsupported database platform you may need to disable the FlywayDB based migrator. Note that this is not recommended, since it is risky to run Smile CDR on an unsupported database platform. However, if you need to do this, you may follow the following steps:

  1. Disable Flyway on Smile CDR startup.

This is done by adding the following line to your bin/setenv file:

JVMARGS="$JVMARGS -Ddisable_flyway=true"
  1. Run the migrator manually without Flyway support

To do this, add the --dont-use-flyway argument when you run the migrator tool.

22.2.4Troubleshooting

 

Under certain unlikely scenarios, you may see the error message "Detected resolved migration not applied to database". This means that Flyway has detected a new migration task that has an earlier version than the latest version in the Flyway table. You can try adding the --out-of-order-permitted argument when you run the migrator tool to permit Flyway to run migration tasks out of order.