XGvfJm1v

1#
2# Copyright 2010-2019 Boxfuse GmbH
3#
4# Licensed under the Apache License, Version 2.0 (the "License");
5# you may not use this file except in compliance with the License.
6# You may obtain a copy of the License at
7#
8#         http://www.apache.org/licenses/LICENSE-2.0
9#
10# Unless required by applicable law or agreed to in writing, software
11# distributed under the License is distributed on an "AS IS" BASIS,
12# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
13# See the License for the specific language governing permissions and
14# limitations under the License.
15#
16
17# JDBC url to use to connect to the database
18# Examples
19# --------
20# Most drivers are included out of the box.
21# * = JDBC driver must be downloaded and installed in /drivers manually
22# ** = TNS_ADMIN environment variable must point to the directory of where tnsnames.ora resides
23# Aurora MySQL      : jdbc:mysql://<instance>.<region>.rds.amazonaws.com:<port>/<database>?<key1>=<value1>&<key2>=<value2>...
24# Aurora PostgreSQL : jdbc:postgresql://<instance>.<region>.rds.amazonaws.com:<port>/<database>?<key1>=<value1>&<key2>=<value2>...
25# CockroachDB       : jdbc:postgresql://<host>:<port>/<database>?<key1>=<value1>&<key2>=<value2>...
26# DB2*              : jdbc:db2://<host>:<port>/<database>
27# Derby             : jdbc:derby:<subsubprotocol>:<database><;attribute=value>
28# Firebird          : jdbc:firebirdsql://<host>[:<port>]/<database>?<key1>=<value1>&<key2>=<value2>...
29# H2                : jdbc:h2:<file>
30# HSQLDB            : jdbc:hsqldb:file:<file>
31# Informix*         : jdbc:informix-sqli://<host>:<port>/<database>:informixserver=dev
32# MariaDB           : jdbc:mariadb://<host>:<port>/<database>?<key1>=<value1>&<key2>=<value2>...
33# MySQL             : jdbc:mysql://<host>:<port>/<database>?<key1>=<value1>&<key2>=<value2>...
34# Oracle*           : jdbc:oracle:thin:@//<host>:<port>/<service>
35# Oracle* (TNS)**   : jdbc:oracle:thin:@<tns_entry>
36# PostgreSQL        : jdbc:postgresql://<host>:<port>/<database>?<key1>=<value1>&<key2>=<value2>...
37# SAP HANA*         : jdbc:sap://<host>:<port>/?databaseName=<database>
38# SQL Server        : jdbc:sqlserver:////<host>:<port>;databaseName=<database>
39# SQLite            : jdbc:sqlite:<database>
40# Sybase ASE        : jdbc:jtds:sybase://<host>:<port>/<database>
41# Redshift*         : jdbc:redshift://<host>:<port>/<database>
42flyway.url=jdbc:postgresql://localhost:5432/test
43
44# Fully qualified classname of the JDBC driver (autodetected by default based on flyway.url)
45# flyway.driver=
46
47# User to use to connect to the database. Flyway will prompt you to enter it if not specified.
48flyway.user=postgres
49
50# Password to use to connect to the database. Flyway will prompt you to enter it if not specified.
51flyway.password=123
52
53# The maximum number of retries when attempting to connect to the database. After each failed attempt,
54# Flyway will wait 1 second before attempting to connect again, up to the maximum number of times specified
55# by connectRetries. (default: 0)
56# flyway.connectRetries=
57
58# The SQL statements to run to initialize a new database connection immediately after opening it. (default: none)
59# flyway.initSql=
60
61# Comma-separated list of schemas managed by Flyway. These schema names are case-sensitive.
62# Consequences:
63# - Flyway will automatically attempt to create all these schemas, unless the first one already exists.
64# - The first schema in the list will be automatically set as the default one during the migration.
65# - The first schema in the list will also be the one containing the schema history table.
66# - The schemas will be cleaned in the order of this list.
67# - If Flyway created them, the schemas themselves will as be dropped when cleaning.
68# (default: The default schema for the database connection)
69# flyway.schemas=flyway
70
71# Name of Flyway's schema history table (default: flyway_schema_history)
72# By default (single-schema mode) the schema history table is placed in the default schema for the connection
73# provided by the datasource.
74# When the flyway.schemas property is set (multi-schema mode), the schema history table is placed in the first
75# schema of the list.
76# flyway.table=
77
78# The tablespace where to create the schema history table that will be used by Flyway.
79# This setting is only relevant for databases that do support the notion of tablespaces. It's value is simply
80# ignored for all others. (default: The default tablespace for the database connection)
81# flyway.tablespace=
82
83# Comma-separated list of locations to scan recursively for migrations. (default: filesystem:<<INSTALL-DIR>>/sql)
84# The location type is determined by its prefix.
85# Unprefixed locations or locations starting with classpath: point to a package on the classpath and may contain
86# both SQL and Java-based migrations.
87# Locations starting with filesystem: point to a directory on the filesystem, may only
88# contain SQL migrations and are only scanned recursively down non-hidden directories.
89# flyway.locations=
90
91# Comma-separated list of fully qualified class names of custom MigrationResolver to use for resolving migrations.
92# flyway.resolvers=
93
94# If set to true, default built-in resolvers (jdbc, spring-jdbc and sql) are skipped and only custom resolvers as
95# defined by 'flyway.resolvers' are used. (default: false)
96# flyway.skipDefaultResolvers=
97
98# Comma-separated list of directories containing JDBC drivers and Java-based migrations.
99# (default: <INSTALL-DIR>/jars)
100# flyway.jarDirs=
101
102# File name prefix for versioned SQL migrations (default: V)
103# Versioned SQL migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix ,
104# which using the defaults translates to V1_1__My_description.sql
105# flyway.sqlMigrationPrefix=
106
107# The file name prefix for undo SQL migrations. (default: U)
108# Undo SQL migrations are responsible for undoing the effects of the versioned migration with the same version.
109# They have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix ,
110# which using the defaults translates to U1.1__My_description.sql
111# Flyway Pro and Flyway Enterprise only
112# flyway.undoSqlMigrationPrefix=
113
114# File name prefix for repeatable SQL migrations (default: R)
115# Repeatable SQL migrations have the following file name structure: prefixSeparatorDESCRIPTIONsuffix ,
116# which using the defaults translates to R__My_description.sql
117# flyway.repeatableSqlMigrationPrefix=
118
119# File name separator for Sql migrations (default: __)
120# Sql migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix ,
121# which using the defaults translates to V1_1__My_description.sql
122# flyway.sqlMigrationSeparator=
123
124# Comma-separated list of file name suffixes for SQL migrations. (default: .sql)
125# SQL migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix ,
126# which using the defaults translates to V1_1__My_description.sql
127# Multiple suffixes (like .sql,.pkg,.pkb) can be specified for easier compatibility with other tools such as
128# editors with specific file associations.
129# flyway.sqlMigrationSuffixes=
130
131# Whether to stream SQL migrations when executing them. (default: false)
132# Streaming doesn't load the entire migration in memory at once. Instead each statement is loaded individually.
133# This is particularly useful for very large SQL migrations composed of multiple MB or even GB of reference data,
134# as this dramatically reduces Flyway's memory consumption.
135# Flyway Pro and Flyway Enterprise only
136# flyway.stream=
137
138# Whether to batch SQL statements when executing them. (default: false)
139# Batching can save up to 99 percent of network roundtrips by sending up to 100 statements at once over the
140# network to the database, instead of sending each statement individually. This is particularly useful for very
141# large SQL migrations composed of multiple MB or even GB of reference data, as this can dramatically reduce
142# the network overhead. This is supported for INSERT, UPDATE, DELETE, MERGE and UPSERT statements.
143# All other statements are automatically executed without batching.
144# Flyway Pro and Flyway Enterprise only
145# flyway.batch=
146
147# Encoding of SQL migrations (default: UTF-8)
148# flyway.encoding=
149
150# Whether placeholders should be replaced. (default: true)
151# flyway.placeholderReplacement=
152
153# Placeholders to replace in Sql migrations
154# flyway.placeholders.user=
155# flyway.placeholders.my_other_placeholder=
156
157# Prefix of every placeholder (default: ${ )
158# flyway.placeholderPrefix=
159
160# Suffix of every placeholder (default: } )
161# flyway.placeholderSuffix=
162
163# Target version up to which Flyway should consider migrations.
164# Defaults to 'latest'
165# Special values:
166# - 'current': designates the current version of the schema
167# - 'latest': the latest version of the schema, as defined by the migration with the highest version
168# flyway.target=
169
170# Whether to automatically call validate or not when running migrate. (default: true)
171# flyway.validateOnMigrate=
172
173# Whether to automatically call clean or not when a validation error occurs. (default: false)
174# This is exclusively intended as a convenience for development. even though we
175# strongly recommend not to change migration scripts once they have been checked into SCM and run, this provides a
176# way of dealing with this case in a smooth manner. The database will be wiped clean automatically, ensuring that
177# the next migration will bring you back to the state checked into SCM.
178# Warning ! Do not enable in production !
179# flyway.cleanOnValidationError=
180
181# Whether to disabled clean. (default: false)
182# This is especially useful for production environments where running clean can be quite a career limiting move.
183# flyway.cleanDisabled=
184
185# The version to tag an existing schema with when executing baseline. (default: 1)
186# flyway.baselineVersion=
187
188# The description to tag an existing schema with when executing baseline. (default: << Flyway Baseline >>)
189# flyway.baselineDescription=
190
191# Whether to automatically call baseline when migrate is executed against a non-empty schema with no schema history
192# table. This schema will then be initialized with the baselineVersion before executing the migrations.
193# Only migrations above baselineVersion will then be applied.
194# This is useful for initial Flyway production deployments on projects with an existing DB.
195# Be careful when enabling this as it removes the safety net that ensures
196# Flyway does not migrate the wrong database in case of a configuration mistake! (default: false)
197# flyway.baselineOnMigrate=
198
199# Allows migrations to be run "out of order" (default: false).
200# If you already have versions 1 and 3 applied, and now a version 2 is found,
201# it will be applied too instead of being ignored.
202# flyway.outOfOrder=
203
204# Whether Flyway should output a table with the results of queries when executing migrations (default: true).
205# Flyway Pro and Flyway Enterprise only
206# flyway.outputQueryResults=
207
208# This allows you to tie in custom code and logic to the Flyway lifecycle notifications (default: empty).
209# Set this to a comma-separated list of fully qualified class names of org.flywaydb.core.api.callback.Callback
210# implementations.
211# flyway.callbacks=
212
213# If set to true, default built-in callbacks (sql) are skipped and only custom callback as
214# defined by 'flyway.callbacks' are used. (default: false)
215# flyway.skipDefaultCallbacks=
216
217# Ignore missing migrations when reading the schema history table. These are migrations that were performed by an
218# older deployment of the application that are no longer available in this version. For example: we have migrations
219# available on the classpath with versions 1.0 and 3.0. The schema history table indicates that a migration with
220# version 2.0 (unknown to us) has also been applied. Instead of bombing out (fail fast) with an exception, a
221# warning is logged and Flyway continues normally. This is useful for situations where one must be able to deploy
222# a newer version of the application even though it doesn't contain migrations included with an older one anymore.
223# Note that if the most recently applied migration is removed, Flyway has no way to know it is missing and will
224# mark it as future instead.
225# true to continue normally and log a warning, false to fail fast with an exception. (default: false)
226# flyway.ignoreMissingMigrations=
227
228# Ignore ignored migrations when reading the schema history table. These are migrations that were added in between
229# already migrated migrations in this version. For example: we have migrations available on the classpath with
230# versions from 1.0 to 3.0. The schema history table indicates that version 1 was finished on 1.0.15, and the next
231# 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
232# by migrate command, but by default is rejected by validate. When ignoreIgnoredMigrations is enabled, such case
233# will not be reported by validate command. This is useful for situations where one must be able to deliver
234# complete set of migrations in a delivery package for multiple versions of the product, and allows for further
235# development of older versions.
236# true to continue normally, false to fail fast with an exception. (default: false)
237# flyway.ignoreIgnoredMigrations=
238
239# Ignore pending migrations when reading the schema history table. These are migrations that are available
240# but have not yet been applied. This can be useful for verifying that in-development migration changes
241# don't contain any validation-breaking changes of migrations that have already been applied to a production
242# environment, e.g. as part of a CI/CD process, without failing because of the existence of new migration versions.
243# (default: false)
244# flyway.ignorePendingMigrations=
245
246# Ignore future migrations when reading the schema history table. These are migrations that were performed by a
247# newer deployment of the application that are not yet available in this version. For example: we have migrations
248# available on the classpath up to version 3.0. The schema history table indicates that a migration to version 4.0
249# (unknown to us) has already been applied. Instead of bombing out (fail fast) with an exception, a
250# warning is logged and Flyway continues normally. This is useful for situations where one must be able to redeploy
251# an older version of the application after the database has been migrated by a newer one.
252# true to continue normally and log a warning, false to fail fast with an exception. (default: true)
253# flyway.ignoreFutureMigrations=
254
255# Whether to allow mixing transactional and non-transactional statements within the same migration. Enabling this
256# automatically causes the entire affected migration to be run without a transaction.
257# Note that this is only applicable for PostgreSQL, Aurora PostgreSQL, SQL Server and SQLite which all have
258# statements that do not run at all within a transaction.
259# This is not to be confused with implicit transaction, as they occur in MySQL or Oracle, where even though a
260# DDL statement was run within within a transaction, the database will issue an implicit commit before and after
261# its execution.
262# true if mixed migrations should be allowed. false if an error should be thrown instead. (default: false)
263# flyway.mixed=
264
265# Whether to group all pending migrations together in the same transaction when applying them
266# (only recommended for databases with support for DDL transactions).
267# true if migrations should be grouped. false if they should be applied individually instead. (default: false)
268# flyway.group=false
269
270# The username that will be recorded in the schema history table as having applied the migration.
271# <<blank>> for the current database user of the connection. (default: <<blank>>).
272# flyway.installedBy=
273
274# Rules for the built-in error handler that let you override specific SQL states and errors codes in order to
275# force specific errors or warnings to be treated as debug messages, info messages, warnings or errors.
276# Each error override has the following format: STATE:12345:W.
277# It is a 5 character SQL state (or * to match all SQL states), a colon,
278# the SQL error code (or * to match all SQL error codes), a colon and finally
279# the desired behavior that should override the initial one.
280# The following behaviors are accepted:
281# - D to force a debug message
282# - D- to force a debug message, but do not show the original sql state and error code
283# - I to force an info message
284# - I- to force an info message, but do not show the original sql state and error code
285# - W to force a warning
286# - W- to force a warning, but do not show the original sql state and error code
287# - E to force an error
288# - E- to force an error, but do not show the original sql state and error code
289# Example 1: to force Oracle stored procedure compilation issues to produce
290# errors instead of warnings, the following errorOverride can be used: 99999:17110:E
291# Example 2: to force SQL Server PRINT messages to be displayed as info messages (without SQL state and error
292# code details) instead of warnings, the following errorOverride can be used: S0001:0:I-
293# Example 3: to force all errors with SQL error code 123 to be treated as warnings instead,
294# the following errorOverride can be used: *:123:W
295# Flyway Pro and Flyway Enterprise only
296# flyway.errorOverrides=
297
298# The file where to output the SQL statements of a migration dry run. If the file specified is in a non-existent
299# directory, Flyway will create all directories and parent directories as needed.
300# <<blank>> to execute the SQL statements directly against the database. (default: <<blank>>)
301# Flyway Pro and Flyway Enterprise only
302# flyway.dryRunOutput=
303
304# Whether to Flyway's support for Oracle SQL*Plus commands should be activated. (default: false)
305# Flyway Pro and Flyway Enterprise only
306# flyway.oracle.sqlplus=
307
308# Whether Flyway should issue a warning instead of an error whenever it encounters an Oracle SQL*Plus
309# statement it doesn't yet support. (default: false)
310# Flyway Pro and Flyway Enterprise only
311# flyway.oracle.sqlplusWarn=
312
313# Your Flyway license key (FL01...). Not yet a Flyway Pro or Enterprise Edition customer?
314# Request your Flyway trial license key st https://flywaydb.org/download/
315# to try out Flyway Pro and Enterprise Edition features free for 30 days.
316# Flyway Pro and Flyway Enterprise only
317# flyway.licenseKey=