#!/bin/bash

migrate_db::label() {
  echo "Migrate database"
}

migrate_db::doc() {
  cat <<EOT
If the database schema has changed for the new version to apply, then migration is required.
Since our internal homegrown database JsonDB only supports a Java-based access, this migration needs to be performed with Java.

A Java CLI tool, which is stored in the `syndesis-server` Docker image and which can be started with `/deployments/migrate-jsondb.sh` takes the following command line arguments:

* Connection parameters to the Postgresql database (URL, user, password)
* A directory holding the migration scripts written in JavaScript

This directory contains a migration script for every schema version:

.Example upgrade directory
```
/upgrade-jsondb/
    ...
    20.js
    21.js
    23.js
    ...
```

Each upgrade script can only upgrade from the prior version. In this example, if the DB is currently at schema `20` and the target schema is `23`, then the scripts `21.js` and `23.js` are executed.

These scripts contain a single javascript function:

.Simple JavaScript API
```javascript
function upgrade(jsondb) {
   // Perform migration by iterating of jsondb documents,
   // transforming them and then storing them back

}
```

with `jsondb` a still to defined context object for accessing, querying and updating JsonDB

These scripts can be part of the `syndesis-server` Docker image so that an outside CLI tool just needs to call

.Starting the migration
```bash
oc port-forward $(pod syndesis-db) 5432:5432
docker run syndesis/syndesis-server --net=host \
     /deployment/migrate-jsondb.sh \
         --url jdbc://localhost:5432 --user admin --password admin \
         --target-schema 23
```

NOTE: The upgrade script and mechanism could also be used internally by the syndesis-server application to perform an upgrade during startup. However, this is recommended only for a development setup as there is no easy way to rollback if things go wrong.

.Rollback
If any of the upgrade scripts fail with an error, a DB rollback needs to be performed.
For this, the backup created in the previous <<step-backup-db, step>> needs to be played back (on a fresh database).
EOT
}

migrate_db::run() {
    local backupdir=${1}
    local workdir=${2}
    local tag=${3}

    local host=${SYNDESIS_DB_SERVICE_HOST:-}
    local port=${SYNDESIS_DB_SERVICE_PORT:-}
    if [ -z "$host" ]; then
        local db_pod=$(pod "syndesis-db")
        check_error $db_pod
        oc port-forward $db_pod 5432 &
        local forward_pid=$!
        trap "kill $forward_pid" EXIT
        sleep 5
        host="localhost"
        port=5432
    fi

    local user=$(extract_param "POSTGRESQL_USER")
    local password=$(extract_param "POSTGRESQL_PASSWORD")

    java -jar $workdir/syndesis-cli.jar migrate \
         --url="jdbc:postgresql://$host:$port/syndesis" \
         --user="$user" \
         --password="$password"
}

migrate_db::rollback() {
    local backupdir=${1}
    local workdir=${2}
    local cleanup=${3:-}

    # Ensure that DB users are really scaled down
    scale_deployments 0 "syndesis-server syndesis-meta"

    pg_restore "$backupdir/db" "syndesis"
}
