From f0d14c55ac10c5d1e8aac0ef139b2305f972d0c3 Mon Sep 17 00:00:00 2001 From: Jose Hernandez Date: Mon, 27 Apr 2020 20:53:57 +0100 Subject: [PATCH] Latest stable changes from develop with support for PostgreSQL 12.2 (#1) * Initial revision * Updated docker image to user PostgreSQL 12 and Java 11. * Made Dockerfile compatible with previous versions of the base image. e.g. postgres:1X-alpine * Added link to question about sending the output of the Docker build to the console. * Removed --version hack from the RUN command used to create the database. See https://github.com/docker-library/postgres/issues/718 for more details. * Added custom entry point. * Updated flyway configuration files and changed entry point to prevent silent migration failures. --- .gitignore | 26 +- README.md | 62 +++- pom.xml | 167 +++++++++ src/main/docker/Dockerfile | 30 ++ src/main/docker/entrypoint.sh | 66 ++++ .../db/configuration/original/flyway.conf | 337 ++++++++++++++++++ .../configuration/postgres/flyway.properties | 337 ++++++++++++++++++ .../R__Repeatable_migration_example_1.sql | 4 + ...PRINT001_01__Initial_database_revision.sql | 2 + 9 files changed, 1006 insertions(+), 25 deletions(-) create mode 100644 pom.xml create mode 100644 src/main/docker/Dockerfile create mode 100644 src/main/docker/entrypoint.sh create mode 100644 src/main/resources/db/configuration/original/flyway.conf create mode 100644 src/main/resources/db/configuration/postgres/flyway.properties create mode 100644 src/main/resources/db/migration/R__Repeatable_migration_example_1.sql create mode 100644 src/main/resources/db/migration/SPRINT001_01__Initial_database_revision.sql diff --git a/.gitignore b/.gitignore index a1c2a23..b4a5277 100644 --- a/.gitignore +++ b/.gitignore @@ -1,23 +1,3 @@ -# Compiled class file -*.class - -# Log file -*.log - -# BlueJ files -*.ctxt - -# Mobile Tools for Java (J2ME) -.mtj.tmp/ - -# Package Files # -*.jar -*.war -*.nar -*.ear -*.zip -*.tar.gz -*.rar - -# virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml -hs_err_pid* +.idea/ +target/ +*.iml diff --git a/README.md b/README.md index 4447519..624cdf0 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,60 @@ -# postgresql -Containerised PostgreSQL database with flyway baked-in +# PostgreSQL database with embedded schema migrator + +Docker image containing a PostgreSQL database and a schema migrator to simplify database schema upgrades. + +## Building the Docker image + +### Using the Maven command line: + +```shell script +mvn clean install +``` + +### Using the Docker command line: +From the top-level directory, run the following command to copy the build assets to the target directory: + +```shell script +mvn compile +``` + +Then go to the target directory and invoke Docker build as shown here: + +```shell script +pushd target/docker +docker build . --tag localhost.localdomain/postgresql-container:latest --no-cache +popd +``` + +## Running the database + +Use the following command to the start the Database in a background docker container: + +```shell script +docker run -p 5432:5432 --name postgres -d localhost.localdomain/postgresql-container:latest +``` + +## Connecting to the database + +Use the following JDBC URL to connect to the database: + +```text +jdbc:postgresql://localhost:5432/postgres +``` +## Extending the database schema + +To extend the schema definition with the tables, data, etc, simply add new idempotent SQL scripts to the +`src/main/resources/db/migration/` folder. + +The SQL script file names must follow the pattern +`SPRINT___.sql` +as shown in this example: `SPRINT001_01__Initial_database_revision.sql`. + +## Resources + +- [PostgreSQL](https://www.postgresql.org) +- [Flyway](https://flywaydb.org) +- [postgres - Docker Official Images](https://hub.docker.com/_/postgres) +- [Docker Library PostgreSQL on GitHub](https://github.com/docker-library/postgres) +- ["exec: \"docker-entrypoint.sh\": executable file not found in $PATH". #296](https://github.com/docker-library/postgres/issues/296) +- [Sending RUN ["docker-entrypoint.sh", "postgres", "--version"] output to the console during the build #718](https://github.com/docker-library/postgres/issues/718) +- [Functionalize the entrypoint to allow outside sourcing for extreme customizing of startup #496](https://github.com/docker-library/postgres/pull/496) diff --git a/pom.xml b/pom.xml new file mode 100644 index 0000000..3e4cded --- /dev/null +++ b/pom.xml @@ -0,0 +1,167 @@ + + + 4.0.0 + org.doraemoncito + postgresql-container + 1.0.0-SNAPSHOT + pom + PostgreSQL container + PostgreSQL database bound with flyway and encapsulated in a docker container + + UTF-8 + UTF-8 + + 11 + 3.6.0 + + ${java.version} + ${java.version} + + localhost.localdomain + ${docker.registry.url}/${project.artifactId} + true + + 1.4.13 + 3.1.2 + 3.1.0 + + 6.3.3 + + + + org.flywaydb + flyway-commandline + ${flyway-commandline.version} + linux-x64 + tar.gz + provided + + + + + + org.apache.maven.plugins + maven-dependency-plugin + ${maven-dependency-plugin.version} + + + + copy + + + + + org.flywaydb + flyway-commandline + ${flyway-commandline.version} + linux-x64 + tar.gz + ${project.build.directory}/docker + false + + + true + true + true + + + + + + org.apache.maven.plugins + maven-resources-plugin + ${maven-resources-plugin.version} + + + copy-scripts + generate-resources + + copy-resources + + + ${project.build.directory}/docker + true + + + src/main/resources + + db/** + + + + + + + copy-docker + generate-resources + + copy-resources + + + ${project.build.directory}/docker + true + + + ${project.basedir}/src/main/docker + + ** + + true + + + + + + + + com.spotify + dockerfile-maven-plugin + ${dockerfile-maven-plugin.version} + + ${docker.image.name} + ${project.build.directory}/docker/Dockerfile + ${project.build.directory}/docker + ${project.version} + + + + + + + false + + + + + build + package + + build + + + + + tag-latest + + tag + + + latest + + + + deploy + deploy + + push + + + ${project.version} + + + + + + + diff --git a/src/main/docker/Dockerfile b/src/main/docker/Dockerfile new file mode 100644 index 0000000..93ad23b --- /dev/null +++ b/src/main/docker/Dockerfile @@ -0,0 +1,30 @@ +FROM postgres:12-alpine +LABEL maintainer="jose.hernandez@bristolalumni.org.uk" +LABEL name="PostgreSQL 12 Database" vendor="Jose Hernandez" +EXPOSE 5432 + +RUN apk --no-cache update upgrade && apk add --no-cache openjdk11 su-exec +COPY db/ /db/ +COPY entrypoint.sh /entrypoint.sh +COPY flyway-commandline.tar.gz /flyway-commandline.tar.gz + +# Install the flyway schema migrator +RUN tar -pxzf flyway-commandline.tar.gz \ + && rm flyway-commandline.tar.gz \ + && mv /flyway-* /flyway \ + && rm -fr /flyway/jre \ + && chmod 777 -R /flyway /db /entrypoint.sh + +# Variables required for the schema migration (i.e. flyway) +ENV PGDATA=/var/lib/postgresql-static/data \ + POSTGRES_DB=postgres \ + POSTGRES_USER=postgres \ + POSTGRES_PASSWORD=password \ + PGPORT=5432 \ +# Uncomment this line to use password authentication, instead of trust, inside the container. +# Please note that using trust authentication generates the following warning in the logs: +# initdb: warning: enabling "trust" authentication for local connections +# POSTGRES_INITDB_ARGS="-A password" \ + JAVA_HOME=/usr/lib/jvm/java-11-openjdk + +RUN ["/entrypoint.sh", "postgres"] diff --git a/src/main/docker/entrypoint.sh b/src/main/docker/entrypoint.sh new file mode 100644 index 0000000..af7853e --- /dev/null +++ b/src/main/docker/entrypoint.sh @@ -0,0 +1,66 @@ +#!/bin/bash + +#!/usr/bin/env bash +set -Eeo pipefail + +# Example using the functions of the postgres entry point to customize startup to always run files in /always-initdb.d/ + +source "$(which docker-entrypoint.sh)" + +docker_setup_env +docker_create_db_directories +# assumption: we are already running as the owner of PGDATA + +# This is needed if the container is started as `root` +if [ "$1" = 'postgres' ] && [ "$(id -u)" = '0' ]; then + exec su-exec postgres "$BASH_SOURCE" "$@" +fi + +echo "Running flyway to update the PostgreSQL database" +PATH=$PATH:/flyway + +echo "============================================================" +echo " PATH: ${PATH}" +echo " PGDATA: ${PGDATA}" +echo " POSTGRES_DB: ${POSTGRES_DB}" +echo " POSTGRES_USER: ${POSTGRES_USER}" +echo " PGPORT: ${PGPORT}" +echo "POSTGRES_INITDB_ARGS: ${POSTGRES_INITDB_ARGS}" +echo "============================================================" + +if [ -z "$DATABASE_ALREADY_EXISTS" ]; then + docker_verify_minimum_env + docker_init_database_dir + pg_setup_hba_conf + + # only required for '--auth[-local]=md5' on POSTGRES_INITDB_ARGS + export PGPASSWORD="${PGPASSWORD:-$POSTGRES_PASSWORD}" + + docker_temp_server_start "$@" -c max_locks_per_transaction=256 + docker_setup_db + + # Ensure that PostgreSQL is restarted after the authentication is set to trust instead of ident so that flyway can + # connect to the database to perform migration. For more details please visit the PostgreSQL documentation page at + # https://www.postgresql.org/docs/11/client-authentication.html + pg_ctl --options "-c listen_addresses='localhost'" --wait restart + + /flyway/flyway -user="$POSTGRES_USER" -password="$POSTGRES_PASSWORD" -configFiles=/db/configuration/postgres/flyway.properties -url="jdbc:postgresql://localhost:$PGPORT/$POSTGRES_DB?user=$POSTGRES_USER" -locations="filesystem:/db/migration" info migrate info || exit 1 + + docker_process_init_files /docker-entrypoint-initdb.d/* + + docker_temp_server_stop +else + docker_temp_server_start "$@" + + # Ensure that PostgreSQL is restarted after the authentication is set to trust instead of ident so that flyway can + # connect to the database to perform migration. For more details please visit the PostgreSQL documentation page at + # https://www.postgresql.org/docs/11/client-authentication.html + pg_ctl --options "-c listen_addresses='localhost'" --wait restart + + /flyway/flyway -user="$POSTGRES_USER" -password="$POSTGRES_PASSWORD" -configFiles=/db/configuration/postgres/flyway.properties -url="jdbc:postgresql://localhost:$PGPORT/$POSTGRES_DB?user=$POSTGRES_USER" -locations="filesystem:/db/migration" info migrate info || exit 1 + + docker_process_init_files /always-initdb.d/* + docker_temp_server_stop +fi + +echo "entrypoint.sh Completed" diff --git a/src/main/resources/db/configuration/original/flyway.conf b/src/main/resources/db/configuration/original/flyway.conf new file mode 100644 index 0000000..6c20954 --- /dev/null +++ b/src/main/resources/db/configuration/original/flyway.conf @@ -0,0 +1,337 @@ +# +# Copyright 2010-2020 Boxfuse GmbH +# +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. +# + +# JDBC url to use to connect to the database +# Examples +# -------- +# Most drivers are included out of the box. +# * = JDBC driver must be downloaded and installed in /drivers manually +# ** = TNS_ADMIN environment variable must point to the directory of where tnsnames.ora resides +# Aurora MySQL : jdbc:mysql://..rds.amazonaws.com:/?=&=... +# Aurora PostgreSQL : jdbc:postgresql://..rds.amazonaws.com:/?=&=... +# CockroachDB : jdbc:postgresql://:/?=&=... +# DB2* : jdbc:db2://:/ +# Derby : jdbc:derby::<;attribute=value> +# Firebird : jdbc:firebirdsql://[:]/?=&=... +# H2 : jdbc:h2: +# HSQLDB : jdbc:hsqldb:file: +# Informix* : jdbc:informix-sqli://:/:informixserver=dev +# MariaDB : jdbc:mariadb://:/?=&=... +# MySQL : jdbc:mysql://:/?=&=... +# Oracle : jdbc:oracle:thin:@//:/ +# Oracle (TNS)** : jdbc:oracle:thin:@ +# PostgreSQL : jdbc:postgresql://:/?=&=... +# SAP HANA* : jdbc:sap://:/?databaseName= +# Snowflake* : jdbc:snowflake://.snowflakecomputing.com/?db=&warehouse=&role=... +# SQL Server : jdbc:sqlserver://:;databaseName= +# SQLite : jdbc:sqlite: +# Sybase ASE : jdbc:jtds:sybase://:/ +# Redshift* : jdbc:redshift://:/ +# flyway.url= + +# Fully qualified classname of the JDBC driver (autodetected by default based on flyway.url) +# flyway.driver= + +# User to use to connect to the database. Flyway will prompt you to enter it if not specified, and if the JDBC +# connection is not using a password-less method of authentication. +# flyway.user= + +# Password to use to connect to the database. Flyway will prompt you to enter it if not specified, and if the JDBC +# connection is not using a password-less method of authentication. +# flyway.password= + +# The maximum number of retries when attempting to connect to the database. After each failed attempt, +# Flyway will wait 1 second before attempting to connect again, up to the maximum number of times specified +# by connectRetries. (default: 0) +# flyway.connectRetries= + +# The SQL statements to run to initialize a new database connection immediately after opening it. (default: none) +# flyway.initSql= + +# The default schema managed by Flyway. This schema name is case-sensitive. If not specified, but flyway.schemas is, Flyway uses the first schema +# in that list. If that is also not specified, Flyway uses the default schema for the database connection. +# Consequences: +# - This schema will be the one containing the schema history table. +# - This schema will be the default for the database connection (provided the database supports this concept). +# flyway.defaultSchema= + +# Comma-separated list of schemas managed by Flyway. These schema names are case-sensitive. If not specified, Flyway uses +# the default schema for the database connection. If flyway.defaultSchema is not specified, then the first of +# this list also acts as default schema. +# Consequences: +# - Flyway will automatically attempt to create all these schemas, unless they already exist. +# - The schemas will be cleaned in the order of this list. +# - If Flyway created them, the schemas themselves will be dropped when cleaning. +# flyway.schemas= + +# Name of Flyway's schema history table (default: flyway_schema_history) +# By default (single-schema mode) the schema history table is placed in the default schema for the connection +# provided by the datasource. +# When the flyway.schemas property is set (multi-schema mode), the schema history table is placed in the first +# schema of the list. +# flyway.table= + +# The tablespace where to create the schema history table that will be used by Flyway. If not specified, Flyway uses +# the default tablespace for the database connection. +# This setting is only relevant for databases that do support the notion of tablespaces. Its value is simply +# ignored for all others. +# flyway.tablespace= + +# Comma-separated list of locations to scan recursively for migrations. (default: filesystem:<>/sql) +# The location type is determined by its prefix. +# Unprefixed locations or locations starting with classpath: point to a package on the classpath and may contain +# both SQL and Java-based migrations. +# Locations starting with filesystem: point to a directory on the filesystem, may only +# contain SQL migrations and are only scanned recursively down non-hidden directories. +# Wildcards can be used to reduce duplication of location paths. (e.g. filesystem:migrations/*/oracle) Supported wildcards: +# ** : Matches any 0 or more directories +# * : Matches any 0 or more non-separator characters +# ? : Matches any 1 non-separator character +# flyway.locations= + +# Comma-separated list of fully qualified class names of custom MigrationResolver to use for resolving migrations. +# flyway.resolvers= + +# If set to true, default built-in resolvers (jdbc, spring-jdbc and sql) are skipped and only custom resolvers as +# defined by 'flyway.resolvers' are used. (default: false) +# flyway.skipDefaultResolvers= + +# Comma-separated list of directories containing JDBC drivers and Java-based migrations. +# (default: /jars) +# flyway.jarDirs= + +# File name prefix for versioned SQL migrations (default: V) +# Versioned SQL migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix , +# which using the defaults translates to V1_1__My_description.sql +# flyway.sqlMigrationPrefix= + +# The file name prefix for undo SQL migrations. (default: U) +# Undo SQL migrations are responsible for undoing the effects of the versioned migration with the same version. +# They have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix , +# which using the defaults translates to U1.1__My_description.sql +# Flyway Pro and Flyway Enterprise only +# flyway.undoSqlMigrationPrefix= + +# File name prefix for repeatable SQL migrations (default: R) +# Repeatable SQL migrations have the following file name structure: prefixSeparatorDESCRIPTIONsuffix , +# which using the defaults translates to R__My_description.sql +# flyway.repeatableSqlMigrationPrefix= + +# File name separator for Sql migrations (default: __) +# Sql migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix , +# which using the defaults translates to V1_1__My_description.sql +# flyway.sqlMigrationSeparator= + +# Comma-separated list of file name suffixes for SQL migrations. (default: .sql) +# SQL migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix , +# which using the defaults translates to V1_1__My_description.sql +# Multiple suffixes (like .sql,.pkg,.pkb) can be specified for easier compatibility with other tools such as +# editors with specific file associations. +# flyway.sqlMigrationSuffixes= + +# Whether to stream SQL migrations when executing them. (default: false) +# Streaming doesn't load the entire migration in memory at once. Instead each statement is loaded individually. +# This is particularly useful for very large SQL migrations composed of multiple MB or even GB of reference data, +# as this dramatically reduces Flyway's memory consumption. +# Flyway Pro and Flyway Enterprise only +# flyway.stream= + +# Whether to batch SQL statements when executing them. (default: false) +# Batching can save up to 99 percent of network roundtrips by sending up to 100 statements at once over the +# network to the database, instead of sending each statement individually. This is particularly useful for very +# large SQL migrations composed of multiple MB or even GB of reference data, as this can dramatically reduce +# the network overhead. This is supported for INSERT, UPDATE, DELETE, MERGE and UPSERT statements. +# All other statements are automatically executed without batching. +# Flyway Pro and Flyway Enterprise only +# flyway.batch= + +# Encoding of SQL migrations (default: UTF-8). Caution: changing the encoding after migrations have been run +# will invalidate the calculated checksums and require a `flyway repair`. +# flyway.encoding= + +# Whether placeholders should be replaced. (default: true) +# flyway.placeholderReplacement= + +# Placeholders to replace in Sql migrations +# flyway.placeholders.user= +# flyway.placeholders.my_other_placeholder= + +# Prefix of every placeholder (default: ${ ) +# flyway.placeholderPrefix= + +# Suffix of every placeholder (default: } ) +# flyway.placeholderSuffix= + +# Target version up to which Flyway should consider migrations. +# Defaults to 'latest' +# Special values: +# - 'current': designates the current version of the schema +# - 'latest': the latest version of the schema, as defined by the migration with the highest version +# flyway.target= + +# Whether to automatically call validate or not when running migrate. (default: true) +# flyway.validateOnMigrate= + +# Whether to automatically call clean or not when a validation error occurs. (default: false) +# This is exclusively intended as a convenience for development. even though we +# strongly recommend not to change migration scripts once they have been checked into SCM and run, this provides a +# way of dealing with this case in a smooth manner. The database will be wiped clean automatically, ensuring that +# the next migration will bring you back to the state checked into SCM. +# Warning ! Do not enable in production ! +# flyway.cleanOnValidationError= + +# Whether to disable clean. (default: false) +# This is especially useful for production environments where running clean can be quite a career limiting move. +# flyway.cleanDisabled= + +# The version to tag an existing schema with when executing baseline. (default: 1) +# flyway.baselineVersion= + +# The description to tag an existing schema with when executing baseline. (default: << Flyway Baseline >>) +# flyway.baselineDescription= + +# Whether to automatically call baseline when migrate is executed against a non-empty schema with no schema history +# table. This schema will then be initialized with the baselineVersion before executing the migrations. +# Only migrations above baselineVersion will then be applied. +# This is useful for initial Flyway production deployments on projects with an existing DB. +# Be careful when enabling this as it removes the safety net that ensures +# Flyway does not migrate the wrong database in case of a configuration mistake! (default: false) +# flyway.baselineOnMigrate= + +# Allows migrations to be run "out of order" (default: false). +# If you already have versions 1 and 3 applied, and now a version 2 is found, +# it will be applied too instead of being ignored. +# flyway.outOfOrder= + +# Whether Flyway should output a table with the results of queries when executing migrations (default: true). +# Flyway Pro and Flyway Enterprise only +# flyway.outputQueryResults= + +# This allows you to tie in custom code and logic to the Flyway lifecycle notifications (default: empty). +# Set this to a comma-separated list of fully qualified class names of org.flywaydb.core.api.callback.Callback +# implementations. +# flyway.callbacks= + +# If set to true, default built-in callbacks (sql) are skipped and only custom callback as +# defined by 'flyway.callbacks' are used. (default: false) +# flyway.skipDefaultCallbacks= + +# Ignore missing migrations when reading the schema history table. These are migrations that were performed by an +# older deployment of the application that are no longer available in this version. For example: we have migrations +# available on the classpath with versions 1.0 and 3.0. The schema history table indicates that a migration with +# version 2.0 (unknown to us) has also been applied. Instead of bombing out (fail fast) with an exception, a +# warning is logged and Flyway continues normally. This is useful for situations where one must be able to deploy +# a newer version of the application even though it doesn't contain migrations included with an older one anymore. +# Note that if the most recently applied migration is removed, Flyway has no way to know it is missing and will +# mark it as future instead. +# true to continue normally and log a warning, false to fail fast with an exception. (default: false) +# flyway.ignoreMissingMigrations= + +# Ignore ignored migrations when reading the schema history table. These are migrations that were added in between +# already migrated migrations in this version. For example: we have migrations available on the classpath with +# versions from 1.0 to 3.0. The schema history table indicates that version 1 was finished on 1.0.15, and the next +# one was 2.0.0. But with the next release a new migration was added to version 1: 1.0.16. Such scenario is ignored +# by migrate command, but by default is rejected by validate. When ignoreIgnoredMigrations is enabled, such case +# will not be reported by validate command. This is useful for situations where one must be able to deliver +# complete set of migrations in a delivery package for multiple versions of the product, and allows for further +# development of older versions. +# true to continue normally, false to fail fast with an exception. (default: false) +# flyway.ignoreIgnoredMigrations= + +# Ignore pending migrations when reading the schema history table. These are migrations that are available +# but have not yet been applied. This can be useful for verifying that in-development migration changes +# don't contain any validation-breaking changes of migrations that have already been applied to a production +# environment, e.g. as part of a CI/CD process, without failing because of the existence of new migration versions. +# (default: false) +# flyway.ignorePendingMigrations= + +# Ignore future migrations when reading the schema history table. These are migrations that were performed by a +# newer deployment of the application that are not yet available in this version. For example: we have migrations +# available on the classpath up to version 3.0. The schema history table indicates that a migration to version 4.0 +# (unknown to us) has already been applied. Instead of bombing out (fail fast) with an exception, a +# warning is logged and Flyway continues normally. This is useful for situations where one must be able to redeploy +# an older version of the application after the database has been migrated by a newer one. +# true to continue normally and log a warning, false to fail fast with an exception. (default: true) +# flyway.ignoreFutureMigrations= + +# Whether to validate migrations and callbacks whose scripts do not obey the correct naming convention. A failure can be +# useful to check that errors such as case sensitivity in migration prefixes have been corrected. +# false to continue normally, true to fail fast with an exception (default: false) +# flyway.validateMigrationNaming= + +# Whether to allow mixing transactional and non-transactional statements within the same migration. Enabling this +# automatically causes the entire affected migration to be run without a transaction. +# Note that this is only applicable for PostgreSQL, Aurora PostgreSQL, SQL Server and SQLite which all have +# statements that do not run at all within a transaction. +# This is not to be confused with implicit transaction, as they occur in MySQL or Oracle, where even though a +# DDL statement was run within within a transaction, the database will issue an implicit commit before and after +# its execution. +# true if mixed migrations should be allowed. false if an error should be thrown instead. (default: false) +# flyway.mixed= + +# Whether to group all pending migrations together in the same transaction when applying them +# (only recommended for databases with support for DDL transactions). +# true if migrations should be grouped. false if they should be applied individually instead. (default: false) +# flyway.group= + +# The username that will be recorded in the schema history table as having applied the migration. +# <> for the current database user of the connection. (default: <>). +# flyway.installedBy= + +# Rules for the built-in error handler that let you override specific SQL states and errors codes in order to +# force specific errors or warnings to be treated as debug messages, info messages, warnings or errors. +# Each error override has the following format: STATE:12345:W. +# It is a 5 character SQL state (or * to match all SQL states), a colon, +# the SQL error code (or * to match all SQL error codes), a colon and finally +# the desired behavior that should override the initial one. +# The following behaviors are accepted: +# - D to force a debug message +# - D- to force a debug message, but do not show the original sql state and error code +# - I to force an info message +# - I- to force an info message, but do not show the original sql state and error code +# - W to force a warning +# - W- to force a warning, but do not show the original sql state and error code +# - E to force an error +# - E- to force an error, but do not show the original sql state and error code +# Example 1: to force Oracle stored procedure compilation issues to produce +# errors instead of warnings, the following errorOverride can be used: 99999:17110:E +# Example 2: to force SQL Server PRINT messages to be displayed as info messages (without SQL state and error +# code details) instead of warnings, the following errorOverride can be used: S0001:0:I- +# Example 3: to force all errors with SQL error code 123 to be treated as warnings instead, +# the following errorOverride can be used: *:123:W +# Flyway Pro and Flyway Enterprise only +# flyway.errorOverrides= + +# The file where to output the SQL statements of a migration dry run. If the file specified is in a non-existent +# directory, Flyway will create all directories and parent directories as needed. +# <> to execute the SQL statements directly against the database. (default: <>) +# Flyway Pro and Flyway Enterprise only +# flyway.dryRunOutput= + +# Whether to Flyway's support for Oracle SQL*Plus commands should be activated. (default: false) +# Flyway Pro and Flyway Enterprise only +# flyway.oracle.sqlplus= + +# Whether Flyway should issue a warning instead of an error whenever it encounters an Oracle SQL*Plus +# statement it doesn't yet support. (default: false) +# Flyway Pro and Flyway Enterprise only +# flyway.oracle.sqlplusWarn= + +# Your Flyway license key (FL01...). Not yet a Flyway Pro or Enterprise Edition customer? +# Request your Flyway trial license key st https://flywaydb.org/download/ +# to try out Flyway Pro and Enterprise Edition features free for 30 days. +# Flyway Pro and Flyway Enterprise only +# flyway.licenseKey= diff --git a/src/main/resources/db/configuration/postgres/flyway.properties b/src/main/resources/db/configuration/postgres/flyway.properties new file mode 100644 index 0000000..f2bdb84 --- /dev/null +++ b/src/main/resources/db/configuration/postgres/flyway.properties @@ -0,0 +1,337 @@ +# +# Copyright 2010-2020 Boxfuse GmbH +# +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. +# + +# JDBC url to use to connect to the database +# Examples +# -------- +# Most drivers are included out of the box. +# * = JDBC driver must be downloaded and installed in /drivers manually +# ** = TNS_ADMIN environment variable must point to the directory of where tnsnames.ora resides +# Aurora MySQL : jdbc:mysql://..rds.amazonaws.com:/?=&=... +# Aurora PostgreSQL : jdbc:postgresql://..rds.amazonaws.com:/?=&=... +# CockroachDB : jdbc:postgresql://:/?=&=... +# DB2* : jdbc:db2://:/ +# Derby : jdbc:derby::<;attribute=value> +# Firebird : jdbc:firebirdsql://[:]/?=&=... +# H2 : jdbc:h2: +# HSQLDB : jdbc:hsqldb:file: +# Informix* : jdbc:informix-sqli://:/:informixserver=dev +# MariaDB : jdbc:mariadb://:/?=&=... +# MySQL : jdbc:mysql://:/?=&=... +# Oracle : jdbc:oracle:thin:@//:/ +# Oracle (TNS)** : jdbc:oracle:thin:@ +# PostgreSQL : jdbc:postgresql://:/?=&=... +# SAP HANA* : jdbc:sap://:/?databaseName= +# Snowflake* : jdbc:snowflake://.snowflakecomputing.com/?db=&warehouse=&role=... +# SQL Server : jdbc:sqlserver://:;databaseName= +# SQLite : jdbc:sqlite: +# Sybase ASE : jdbc:jtds:sybase://:/ +# Redshift* : jdbc:redshift://:/ +flyway.url= + +# Fully qualified classname of the JDBC driver (autodetected by default based on flyway.url) +# flyway.driver= + +# User to use to connect to the database. Flyway will prompt you to enter it if not specified, and if the JDBC +# connection is not using a password-less method of authentication. +# flyway.user= + +# Password to use to connect to the database. Flyway will prompt you to enter it if not specified, and if the JDBC +# connection is not using a password-less method of authentication. +# flyway.password= + +# The maximum number of retries when attempting to connect to the database. After each failed attempt, +# Flyway will wait 1 second before attempting to connect again, up to the maximum number of times specified +# by connectRetries. (default: 0) +# flyway.connectRetries= + +# The SQL statements to run to initialize a new database connection immediately after opening it. (default: none) +# flyway.initSql= + +# The default schema managed by Flyway. This schema name is case-sensitive. If not specified, but flyway.schemas is, Flyway uses the first schema +# in that list. If that is also not specified, Flyway uses the default schema for the database connection. +# Consequences: +# - This schema will be the one containing the schema history table. +# - This schema will be the default for the database connection (provided the database supports this concept). +# flyway.defaultSchema= + +# Comma-separated list of schemas managed by Flyway. These schema names are case-sensitive. If not specified, Flyway uses +# the default schema for the database connection. If flyway.defaultSchema is not specified, then the first of +# this list also acts as default schema. +# Consequences: +# - Flyway will automatically attempt to create all these schemas, unless they already exist. +# - The schemas will be cleaned in the order of this list. +# - If Flyway created them, the schemas themselves will be dropped when cleaning. +# flyway.schemas= + +# Name of Flyway's schema history table (default: flyway_schema_history) +# By default (single-schema mode) the schema history table is placed in the default schema for the connection +# provided by the datasource. +# When the flyway.schemas property is set (multi-schema mode), the schema history table is placed in the first +# schema of the list. +# flyway.table= + +# The tablespace where to create the schema history table that will be used by Flyway. If not specified, Flyway uses +# the default tablespace for the database connection. +# This setting is only relevant for databases that do support the notion of tablespaces. Its value is simply +# ignored for all others. +# flyway.tablespace= + +# Comma-separated list of locations to scan recursively for migrations. (default: filesystem:<>/sql) +# The location type is determined by its prefix. +# Unprefixed locations or locations starting with classpath: point to a package on the classpath and may contain +# both SQL and Java-based migrations. +# Locations starting with filesystem: point to a directory on the filesystem, may only +# contain SQL migrations and are only scanned recursively down non-hidden directories. +# Wildcards can be used to reduce duplication of location paths. (e.g. filesystem:migrations/*/oracle) Supported wildcards: +# ** : Matches any 0 or more directories +# * : Matches any 0 or more non-separator characters +# ? : Matches any 1 non-separator character +# flyway.locations= + +# Comma-separated list of fully qualified class names of custom MigrationResolver to use for resolving migrations. +# flyway.resolvers= + +# If set to true, default built-in resolvers (jdbc, spring-jdbc and sql) are skipped and only custom resolvers as +# defined by 'flyway.resolvers' are used. (default: false) +# flyway.skipDefaultResolvers= + +# Comma-separated list of directories containing JDBC drivers and Java-based migrations. +# (default: /jars) +# flyway.jarDirs= + +# File name prefix for versioned SQL migrations (default: V) +# Versioned SQL migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix , +# which using the defaults translates to V1_1__My_description.sql +flyway.sqlMigrationPrefix=SPRINT + +# The file name prefix for undo SQL migrations. (default: U) +# Undo SQL migrations are responsible for undoing the effects of the versioned migration with the same version. +# They have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix , +# which using the defaults translates to U1.1__My_description.sql +# Flyway Pro and Flyway Enterprise only +# flyway.undoSqlMigrationPrefix= + +# File name prefix for repeatable SQL migrations (default: R) +# Repeatable SQL migrations have the following file name structure: prefixSeparatorDESCRIPTIONsuffix , +# which using the defaults translates to R__My_description.sql +# flyway.repeatableSqlMigrationPrefix= + +# File name separator for Sql migrations (default: __) +# Sql migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix , +# which using the defaults translates to V1_1__My_description.sql +# flyway.sqlMigrationSeparator= + +# Comma-separated list of file name suffixes for SQL migrations. (default: .sql) +# SQL migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix , +# which using the defaults translates to V1_1__My_description.sql +# Multiple suffixes (like .sql,.pkg,.pkb) can be specified for easier compatibility with other tools such as +# editors with specific file associations. +# flyway.sqlMigrationSuffixes= + +# Whether to stream SQL migrations when executing them. (default: false) +# Streaming doesn't load the entire migration in memory at once. Instead each statement is loaded individually. +# This is particularly useful for very large SQL migrations composed of multiple MB or even GB of reference data, +# as this dramatically reduces Flyway's memory consumption. +# Flyway Pro and Flyway Enterprise only +# flyway.stream= + +# Whether to batch SQL statements when executing them. (default: false) +# Batching can save up to 99 percent of network roundtrips by sending up to 100 statements at once over the +# network to the database, instead of sending each statement individually. This is particularly useful for very +# large SQL migrations composed of multiple MB or even GB of reference data, as this can dramatically reduce +# the network overhead. This is supported for INSERT, UPDATE, DELETE, MERGE and UPSERT statements. +# All other statements are automatically executed without batching. +# Flyway Pro and Flyway Enterprise only +# flyway.batch= + +# Encoding of SQL migrations (default: UTF-8). Caution: changing the encoding after migrations have been run +# will invalidate the calculated checksums and require a `flyway repair`. +# flyway.encoding= + +# Whether placeholders should be replaced. (default: true) +# flyway.placeholderReplacement= + +# Placeholders to replace in Sql migrations +# flyway.placeholders.user= +# flyway.placeholders.my_other_placeholder= + +# Prefix of every placeholder (default: ${ ) +# flyway.placeholderPrefix= + +# Suffix of every placeholder (default: } ) +# flyway.placeholderSuffix= + +# Target version up to which Flyway should consider migrations. +# Defaults to 'latest' +# Special values: +# - 'current': designates the current version of the schema +# - 'latest': the latest version of the schema, as defined by the migration with the highest version +# flyway.target= + +# Whether to automatically call validate or not when running migrate. (default: true) +# flyway.validateOnMigrate= + +# Whether to automatically call clean or not when a validation error occurs. (default: false) +# This is exclusively intended as a convenience for development. even though we +# strongly recommend not to change migration scripts once they have been checked into SCM and run, this provides a +# way of dealing with this case in a smooth manner. The database will be wiped clean automatically, ensuring that +# the next migration will bring you back to the state checked into SCM. +# Warning ! Do not enable in production ! +# flyway.cleanOnValidationError= + +# Whether to disable clean. (default: false) +# This is especially useful for production environments where running clean can be quite a career limiting move. +# flyway.cleanDisabled= + +# The version to tag an existing schema with when executing baseline. (default: 1) +# flyway.baselineVersion= + +# The description to tag an existing schema with when executing baseline. (default: << Flyway Baseline >>) +# flyway.baselineDescription= + +# Whether to automatically call baseline when migrate is executed against a non-empty schema with no schema history +# table. This schema will then be initialized with the baselineVersion before executing the migrations. +# Only migrations above baselineVersion will then be applied. +# This is useful for initial Flyway production deployments on projects with an existing DB. +# Be careful when enabling this as it removes the safety net that ensures +# Flyway does not migrate the wrong database in case of a configuration mistake! (default: false) +# flyway.baselineOnMigrate= + +# Allows migrations to be run "out of order" (default: false). +# If you already have versions 1 and 3 applied, and now a version 2 is found, +# it will be applied too instead of being ignored. +# flyway.outOfOrder= + +# Whether Flyway should output a table with the results of queries when executing migrations (default: true). +# Flyway Pro and Flyway Enterprise only +# flyway.outputQueryResults= + +# This allows you to tie in custom code and logic to the Flyway lifecycle notifications (default: empty). +# Set this to a comma-separated list of fully qualified class names of org.flywaydb.core.api.callback.Callback +# implementations. +# flyway.callbacks= + +# If set to true, default built-in callbacks (sql) are skipped and only custom callback as +# defined by 'flyway.callbacks' are used. (default: false) +# flyway.skipDefaultCallbacks= + +# Ignore missing migrations when reading the schema history table. These are migrations that were performed by an +# older deployment of the application that are no longer available in this version. For example: we have migrations +# available on the classpath with versions 1.0 and 3.0. The schema history table indicates that a migration with +# version 2.0 (unknown to us) has also been applied. Instead of bombing out (fail fast) with an exception, a +# warning is logged and Flyway continues normally. This is useful for situations where one must be able to deploy +# a newer version of the application even though it doesn't contain migrations included with an older one anymore. +# Note that if the most recently applied migration is removed, Flyway has no way to know it is missing and will +# mark it as future instead. +# true to continue normally and log a warning, false to fail fast with an exception. (default: false) +# flyway.ignoreMissingMigrations= + +# Ignore ignored migrations when reading the schema history table. These are migrations that were added in between +# already migrated migrations in this version. For example: we have migrations available on the classpath with +# versions from 1.0 to 3.0. The schema history table indicates that version 1 was finished on 1.0.15, and the next +# one was 2.0.0. But with the next release a new migration was added to version 1: 1.0.16. Such scenario is ignored +# by migrate command, but by default is rejected by validate. When ignoreIgnoredMigrations is enabled, such case +# will not be reported by validate command. This is useful for situations where one must be able to deliver +# complete set of migrations in a delivery package for multiple versions of the product, and allows for further +# development of older versions. +# true to continue normally, false to fail fast with an exception. (default: false) +# flyway.ignoreIgnoredMigrations= + +# Ignore pending migrations when reading the schema history table. These are migrations that are available +# but have not yet been applied. This can be useful for verifying that in-development migration changes +# don't contain any validation-breaking changes of migrations that have already been applied to a production +# environment, e.g. as part of a CI/CD process, without failing because of the existence of new migration versions. +# (default: false) +# flyway.ignorePendingMigrations= + +# Ignore future migrations when reading the schema history table. These are migrations that were performed by a +# newer deployment of the application that are not yet available in this version. For example: we have migrations +# available on the classpath up to version 3.0. The schema history table indicates that a migration to version 4.0 +# (unknown to us) has already been applied. Instead of bombing out (fail fast) with an exception, a +# warning is logged and Flyway continues normally. This is useful for situations where one must be able to redeploy +# an older version of the application after the database has been migrated by a newer one. +# true to continue normally and log a warning, false to fail fast with an exception. (default: true) +# flyway.ignoreFutureMigrations= + +# Whether to validate migrations and callbacks whose scripts do not obey the correct naming convention. A failure can be +# useful to check that errors such as case sensitivity in migration prefixes have been corrected. +# false to continue normally, true to fail fast with an exception (default: false) +# flyway.validateMigrationNaming= + +# Whether to allow mixing transactional and non-transactional statements within the same migration. Enabling this +# automatically causes the entire affected migration to be run without a transaction. +# Note that this is only applicable for PostgreSQL, Aurora PostgreSQL, SQL Server and SQLite which all have +# statements that do not run at all within a transaction. +# This is not to be confused with implicit transaction, as they occur in MySQL or Oracle, where even though a +# DDL statement was run within within a transaction, the database will issue an implicit commit before and after +# its execution. +# true if mixed migrations should be allowed. false if an error should be thrown instead. (default: false) +# flyway.mixed= + +# Whether to group all pending migrations together in the same transaction when applying them +# (only recommended for databases with support for DDL transactions). +# true if migrations should be grouped. false if they should be applied individually instead. (default: false) +# flyway.group= + +# The username that will be recorded in the schema history table as having applied the migration. +# <> for the current database user of the connection. (default: <>). +# flyway.installedBy= + +# Rules for the built-in error handler that let you override specific SQL states and errors codes in order to +# force specific errors or warnings to be treated as debug messages, info messages, warnings or errors. +# Each error override has the following format: STATE:12345:W. +# It is a 5 character SQL state (or * to match all SQL states), a colon, +# the SQL error code (or * to match all SQL error codes), a colon and finally +# the desired behavior that should override the initial one. +# The following behaviors are accepted: +# - D to force a debug message +# - D- to force a debug message, but do not show the original sql state and error code +# - I to force an info message +# - I- to force an info message, but do not show the original sql state and error code +# - W to force a warning +# - W- to force a warning, but do not show the original sql state and error code +# - E to force an error +# - E- to force an error, but do not show the original sql state and error code +# Example 1: to force Oracle stored procedure compilation issues to produce +# errors instead of warnings, the following errorOverride can be used: 99999:17110:E +# Example 2: to force SQL Server PRINT messages to be displayed as info messages (without SQL state and error +# code details) instead of warnings, the following errorOverride can be used: S0001:0:I- +# Example 3: to force all errors with SQL error code 123 to be treated as warnings instead, +# the following errorOverride can be used: *:123:W +# Flyway Pro and Flyway Enterprise only +# flyway.errorOverrides= + +# The file where to output the SQL statements of a migration dry run. If the file specified is in a non-existent +# directory, Flyway will create all directories and parent directories as needed. +# <> to execute the SQL statements directly against the database. (default: <>) +# Flyway Pro and Flyway Enterprise only +# flyway.dryRunOutput= + +# Whether to Flyway's support for Oracle SQL*Plus commands should be activated. (default: false) +# Flyway Pro and Flyway Enterprise only +# flyway.oracle.sqlplus= + +# Whether Flyway should issue a warning instead of an error whenever it encounters an Oracle SQL*Plus +# statement it doesn't yet support. (default: false) +# Flyway Pro and Flyway Enterprise only +# flyway.oracle.sqlplusWarn= + +# Your Flyway license key (FL01...). Not yet a Flyway Pro or Enterprise Edition customer? +# Request your Flyway trial license key st https://flywaydb.org/download/ +# to try out Flyway Pro and Enterprise Edition features free for 30 days. +# Flyway Pro and Flyway Enterprise only +# flyway.licenseKey= diff --git a/src/main/resources/db/migration/R__Repeatable_migration_example_1.sql b/src/main/resources/db/migration/R__Repeatable_migration_example_1.sql new file mode 100644 index 0000000..93b8a43 --- /dev/null +++ b/src/main/resources/db/migration/R__Repeatable_migration_example_1.sql @@ -0,0 +1,4 @@ +--Repeatable migration script + +-- Get the database version +SELECT version(); diff --git a/src/main/resources/db/migration/SPRINT001_01__Initial_database_revision.sql b/src/main/resources/db/migration/SPRINT001_01__Initial_database_revision.sql new file mode 100644 index 0000000..8ae9533 --- /dev/null +++ b/src/main/resources/db/migration/SPRINT001_01__Initial_database_revision.sql @@ -0,0 +1,2 @@ +-- Initial database revision +