Several locations link to /licenses/flyway-trial. These links currently redirect to the home page.

hi, here's my flywaydb question:

I got 3 git branches: develop, fixbug, and master.

The latest FlywayDB script version in branch master is 1.2.43,
and the one in branch develop is 1.2.54.
Branch fixbug's script version is update to 1.2.55, and it is based on branch master.

I need to merge branch fixbug to branch master, and to deploy master(version 1.2.55) to production environment first. As we know, flywayDB executes scripts in order, from low version to high version. If I do so, when I deploy branch develop(version 1.2.54) to the production evironment, the scripts will not be executed or even assert errors.

How should I do? Thanks!!

On this page
https://flywaydb.org/documentation/callbacks
The button at the bottom of the page [Error Handlers] doesn't work. I strongly suspect it should point to .../erroroverrides rather than .../errorhandlers

Similarly
https://flywaydb.org/documentation/articles
points to a misnamed videos link. Minor typo in the link breaks it.

On this page
https://flywaydb.org/documentation/database/sqlserver
The link in the following text is broken
"the first schema is not set as the default due to SQL Server limitations"
I have no guess where that page may have moved to though since I don't know what it said. Sorry.

Here:

it says that the overriding order is:

System properties > External config file > Maven properties > Plugin configuration

I believe a comment on this whether this means "System properties are overridden by external config, which is overwritten by..." or "System properties override external config, which overwrite maven properties..." would be helpful.

I've a bit of feedback on the documentation as someone completely fresh to Flyway: Specifically I'm getting my feet wet on this page:

https://github.com/flyway/flywaydb.org/blob/gh-pages/documentation/existing.html

At the moment the documentation states:

For all databases with unimportant data you don't mind losing, perform flyway clean to completely remove their contents.

from reading this top to bottom, I've got as far as setting up a fresh maven install, and Flyway seems to be "working" - my main queries are "how" it's working. For example: the docs haven't told me how has flyway at this point connected to my database? Is running flyway:clean going to wipe a local database?, or some internal database? As someone just trying to get up and running for the first time, I'd want to know that.

My other point for feedback is that the documentation jumps from singular to plural "database" to "databases" without much explanation.

These are the steps to follow to successfully integrate Flyway in a project with an existing database.

Then we go to :

Align the remaining databases with production

Give these databases

and the others will be left as is.

the empty databases will be migrated to the state of production and the others will be left as is.
As soon as you add a new migration, it will be applied identically to all databases.

At this point I'm in puzzled land. I'm just trying to get my feet wet with one production database, one initial migration and now I'm wondering if flyway is somehow going to take a snapshot of my entire MySQL schema somehow, which conflicts with my thinking that one DDL ( V1__Base_version.sql) has been created per database?

There's some reference to an H2 file throughout the docs too, without much explanation where that came from assume that this is an internal database used by Flyway? Is schema history table used inside this internal database, or created inside your production database.

Database: jdbc:h2:file:./foobardb (H2 1.4)

Sorry for the plethora of queries, but just a 5 minute bit of feedback from someone coming completely blind to the project.

When Snowflake data warehouse is used for migration using FlywayRunner plugin Jenkins pipeline, it doesn't work as expected.

Flyway is configured with respective Snowflake driver to be installed for migration as in below image.

While providing warehouse name in database URL string, it produces error as:

'**warehouse' is not recognized as an internal or external command, operable program or batch file.**

It seems as it is unable to interpret warehouse parameter. If a Snowflake user is not associated with warehouse then they won't be able to migrate anyhow!! Even if a script contains which warehouse to be used while migration, Flyway seek it prior to looking into migration scripts.

This causes a roadblock if you want to migrate Snowflake using Flyway on Jenkins, basically CI-CD for Snowflake.

Version configuration information:

Jenkins version: 2.260
Available respective FlywayRunner version: 1.9 (FlywayRunner)
Installed Flyway version by Jenkins: 6.5.7
Installed Snowflake driver version by Flyway : 3.11.1

In the Naming section of

http://flywaydb.org/documentation/migration/java.html

If you need more control over the class name, ...

I would suggest

If you need more control over the version naming than the class name gives you, ...

This could hopefully save someone else some time if they're copying the example from the site and slightly modifying their own code.

Add
package db.migration;

To the java.html page where the code example is given.
http://flywaydb.org/documentation/migration/java.html

Yesterday (Thurdsay Dec. 17), one of our SBT builds started failing because this dependency went missing:

https://flywaydb.org/repo/org/flywaydb/flyway-sbt_2.10_0.13/4.2.0/flyway-sbt-4.2.0.jar

I can no longer see it on the website; the link now gives a 404. We can work around this for now because there are mirror repositories that still have the package, but this not a permanent solution.

Thanks.

We've had someone assume TimescaleDB is not supported as it's not explicitly mentioned in the docs, yet other users have seen it's near enough to Postgres to simply be used like Postgres (same driver, URL format etc). Can we clarify please?

Just tried "First Steps: Command-line" and I had to issues.

Before running the first "flyway migrate" flyway told me his metadata table is missing

ERROR: Found non-empty schema "TEST" without metadata table! Use init() or set initOnMigrate to true to init
ialize the metadata table.
ERROR: Caused by: org.flywaydb.core.api.FlywayException: Found non-empty schema "TEST" without metadata tabl
e! Use init() or set initOnMigrate to true to initialize the metadata table.
ERROR: Occured in org.flywaydb.core.Flyway$1.execute() at line 840

So I had to first run "flyway init".

My second issue with the tutorial was, I created a file named " V1__Create_person_table.sql" and flyway told me

Validated 1 migration (execution time 00:00.018s)
Current version of schema "TEST": 1
Schema "TEST" is up to date. No migration necessary.

So it worked by setting version to 2. Or did I miss some instructions before? Tried to follow the guide as exactly as possible.

The documentation for the command line package does not mention the org.flywaydb:flyway-commandline artifact available on maven, its capabilities or dependencies. Is this a deliberate omission? I can see that it might be unnecessary information for users just interested in straight command line functionality, but I'm interested in bundling both it and flyway-core with our software and it would be good to know whether I'm taking advantage of an undocumented package that may or may not exist in the future, or a supported package that can expect to receive updates. I'd be happy to submit a PR but I don't know what is intentional, what is not, and what is an implementation detail.

More specifically, the information I'd like to see:

• Mention of the org.flywaydb:flyway-commandline maven artifact, with a <dependency> snippet similar to that for flyway-core
• Whether its database driver dependencies are compile or runtime

My use case is that I support an application (a game) for which users each have their own local database. Our application performs migrations automatically with flyway-core, but we want to support users in installing mods, as well as providing scripts with which they can create or update their databases themselves. For this we'd like to bundle the additional command line functionality in our maven builds, without rewriting it ourselves and without needing to include all the other drivers that we don't support.

Apologies for doing this the wrong way round.
I have just submitted a PR for the changes.
I added code to detect the AS400 and deal with the catalogs in the way documented by IBM.

try {
ClassUtils.instantiate(className, classLoader);
} catch (Exception e) {
throw new FlywayException("Unable to instantiate class: " + className);
}

with that, I have no chance to debug my code in order to find out why the instantiation fails. The original exception should be added as cause to FlywayException.

We resolved this issue:

flyway/flyway#2641

but it highlighted that our documentation around logging needs to be improved. Can we add some information about configuring log4j?

...
    <p>
        Download the following files from the <a
            href="http://www.oracle.com/technetwork/java/javase/downloads/index.html">Oracle website</a>:
    </p>

    <ul>
        <li>Windows x64 Server JRE 8u31</li>
        <li>Linux x64 Server JRE 8u31</li>
        <li>Mac OSX x64 JRE 8u31</li>
    </ul>

    <p>and place them in your local maven repository as</p>

    <ul>
        <li>~/.m2/repository/com/oracle/server-jre/8.31/server-jre-8.31-windows-x64.tar.gz</li>
        <li>~/.m2/repository/com/oracle/server-jre/8.31/server-jre-8.31-linux-x64.tar.gz</li>
        <li>~/.m2/repository/com/oracle/jre/8.31/jre-8.31-macosx-x64.tar.gz</li>
    </ul>
...

When I first read this, I just tried to copy the files into those specific locations. That doesn't work of course, they have to be installed via the maven install command. Seems like the documentation could benefit from that detail.

Here's the commands I used, assuming the tar.gz files are in the current dir

mvn install:install-file -DgroupId=com.oracle \
-DartifactId=server-jre \
-Dclassifier=windows-x64 \
-Dtype=tar.gz \
-Dversion=8.74 \
-Dpackaging=tar.gz \
-Dfile=server-jre-8u74-windows-x64.tar.gz

mvn install:install-file -DgroupId=com.oracle \
-DartifactId=server-jre \
-Dclassifier=linux-x64 \
-Dtype=tar.gz \
-Dversion=8.74 \
-Dpackaging=tar.gz \
-Dfile=server-jre-8u74-linux-x64.tar.gz

mvn install:install-file -DgroupId=com.oracle \
-DartifactId=jre \
-Dclassifier=macosx-x64 \
-Dtype=tar.gz \
-Dversion=8.74 \
-Dpackaging=tar.gz \
-Dfile=jre-8u74-macosx-x64.tar.gz

Not sure if this is something that people are expected to know, but just wanted to note that it threw me off for a little bit.

Issue to track outsiding docs pages I think we need

• Schema history table description
• How to add things to the classpath
• Find out what FLYWAY_IGNORE_INVALID_MIGRATION_NAMES is supposed to be
• Find out why no env variable support for validateMigrationNaming
• Add cross links in repair to config params
• Find all cases across the site of config params being referenced and change them to links
• Add index.md page
• Add links in sidebar (maybe only after collapse support)
• Update endpoint pages to link to config param list
• Go through blogs and add links from config to blog they are exampled
• Flesh out validate docs, and link to config params
• Link to config params from each command page
• PLACEHOLDERS_PROPERTY_PREFIX and JDBC_PROPERTIES_PREFIX has odd usage

Based on Google CLA: https://developers.google.com/open-source/cla/individual

The example given for flyway.baselineOnMigrate calls baseline instead of what I think should have been the example migrate.

The CockroachDB docs page (https://flywaydb.org/documentation/database/cockroachdb) has out-of-date supported versions. The page currently lists v19.2 as the latest supported version.

Based on flyway/flyway#2976 it should say that the latest supported version is v20.2.

CockroachDB also has its own docs page discussing Flyway support. (https://www.cockroachlabs.com/docs/stable/flyway.html) Perhaps the Flyway docs could link there.

As I see, my chocolatey package is already there but there are some more I maintain or co-maintain.

These are the nuget package at https://www.nuget.org/packages/Flyway.CommandLine and the Cake Build plugin at https://github.com/buthomas/Cake.Flyway

Would be great to have them added as well.

Right now, it is unclear to me, if I can have Flyway to play nice with DI. More precisely, I'd like my DI system to inject into JDBC Migrations. Right now, I put the Injector into a static variable, but that doesn't seem quite right.

Suggestion: Invent a new interface, say

public class IObjectFactory {
Object newInstance(String pClassName);
}

and make the Flyway class to use that interface. A default implementation would be trivial:

public class DefaultObjectFactory {
protected abstract ClassLoader getClassLoader(); // Delegate to Flyway.getClassLoader().
public Object newInstance(String pClassName) {
final ClassLoader cl = getClassLoader();
if (cl == null) {
return Class.forName(pClassName);
} else {
return cl.loadClass(pClassName);
}
}

For Guice, I'd implement a custom implementation like this:

public class GuiceObjectFactory extends DefaultObjectFactory {
private final Injector injecor;

public Object newInstance(String pClassName) {
final Object instance = super.newInstance(pClassName);
injector.injectMembers(instance);
}

Let me know, if you'd like to see a pull request.

Some queries are only working for DB2 UDB linux/windows version but not for DB2 AS/400

eg:
system schema is different (SYSIBM instead of SYSCAT, ...)
fields are different (SCHEMA_NAME instead of SCHEMANAME, ...)
field values are different (table type is 'BASE TABLE' instead of 'T')
...

I propose to commit some code to detect the right naming convention in function of the DB2 flavour

Hello, I have encountered some parameter resolution problems. Flywaydb cannot parse the ${} parameter content, and the parsed fields contain a large amount of $content. Do you have any good solutions？
The parameters are as follows:

INSERT INTO `test` VALUES (67, 1, 'checkHostJdk', '#!/bin/sh\nversion=${jdkVersion}\n\nfunction version_ge() { test \"$(echo \"$@\" | tr \" \" \"\\n\" | \"$1\"; }\n\nhasJava=`whereis java | awk \'{print $2}\'`\nif [ -z \"$hasJava\" ]; then\n   awk \'{print $3}\'`\n\nif version_ge $nowJava $version; then\n    echo \"success $nowJava 大于指定版本 $version\"\n 2);

Hi there,

I was attempting to download the trial edition of Flyway for evaluation at my company. I could not seem to download the zip file (click trial button, get an accept license popup, navigate to "thank you" page but no download).

I did some inspection and I think somehow my company's proxy or firewall is blocking the request with 407 and 404 response codes. I'm not sure if there's anything you can do on your end, but I wanted to point this out as a potential issue for you, considering I'm sure you'd like to sell more pro/enterprises licenses, and perhaps others behind a proxy are missing the download as well.

See screenshot for reference. I was able to directly load the /downloads/flyway-trial-edition page and got a directory listing. I was also able to download the ZIP file eventually this way (direct URL), but I'm not sure if others might be as curious as myself to dig in there and find it.

Hope this helps!

The MySQL page should mention that when using output generated by mysqldump using the option --hex-blob is strongly advised when using UTF-8 encoded data.

I tried dumping a Mediwiki database (with the db using CHARSET=BINARY tables ) with mysqldump and re-importing it with Flyway, rendering the Wiki non-functional due to encoding issues in the i18n cache. After using the --hex-blob option everything was fine.

docs is wrong. https://flywaydb.org/getstarted/firststeps/commandline

$ vi flyway.conf
flyway.url=jdbc:h2:file:./foobardb
flyway.user=SA
flyway.password=

$ vi V1__Create_person_table.sql
create table PERSON (
    ID int not null,
    NAME varchar(100) not null
);

bad result:

$ flyway migrate
Flyway Community Edition 6.3.1 by Redgate
Database: jdbc:h2:file:./foobardb (H2 1.4)
Successfully validated 0 migrations (execution time 00:00.010s)
WARNING: No migrations found. Are your locations set up correctly?
Creating Schema History table "PUBLIC"."flyway_schema_history" ...
Current version of schema "PUBLIC": << Empty Schema >>
Schema "PUBLIC" is up to date. No migration necessary.

The documentation for flyway migrate states the following about the defaultSchema and schemas parameters, respectively:

• For Flyway 6.1 and later, if this schema is not specified then it will default to the first member of schemas.
• For Flyway 6.1 and later, defaultSchema will default to the first member of this list if not explicitly specified.

This was misleading to us, as we understood it to say “until Flyway 6.1, you had to specify defaultSchema, for later versions, it will default to the first schema specified“. Which is wrong; in fact, for Flyway older than 6.1, the defaultSchema parameter is not supported at all, and you should use schemas only, with the first member specifying the default schema. (And also, to use defaultSchema in the newer versions, you have to use schemas as well. That is not explicitly said, which might help as well.)

IMHO you should drop the “For Flyway 6.1 and later” from the text as it is: for older Flyway versions, the sentence has no meaning anyway, there is no defaultSchema at all. If you want to explain the change in 6.1, then add a note about defaultSchema only being supported in Flyway 6.1 and later, because that is the change which occurred.

I was looking for a way to introduce parameters to my sql script, but I only found references to the command-line. It wasn't until I found a stackoverflow answer mentioning a (dead link containing the word) placeholders that I realized that they were named placeholders. This was while I was looking for exactly that functionality.

Placeholders are a powerful tool. However, in the documentation they only get a single paragraph on a different page. I was unable to find them until I found out what they were called, and I suspect people not looking for exactly this will have an even harder time finding out about them. I think it would be good to give placeholders their own page in the documentation. That would mean that they can be found in the navigation on the left side of the page, and it's not as easy to skip over the single paragraph. Expanding that single paragraph would also be good, but giving them their own page is more pressing in my opinion.

No more dead ends

I started with a post on StackOverflow:

https://stackoverflow.com/questions/59360643/implementing-flyway-in-an-existing-project

But have gotten no real help there. As stated in that post, this is an existing project that I inherited. I am trying to integrate Flyway into this project to handle the v2 migration and future migrations.

If I understand the Spring docs and the matching Flyway docs, all I have to do is add the Maven dependency listed in the Flyway docs that I linked. I have done that, and only that (I have made other previous attempts to do more complicated things, but have backed out all of those changes). So the only changes from my previously working project are:

1. Add the Maven dependency
2. Comment out this line in my applicationContext.xml:
   <!-- <prop key="hibernate.hbm2ddl.auto">update</prop> -->
   so that Hibernate will not update the database.

But with those minimal changes, my project will not run:
Dec 18, 2019 9:18:34 AM org.springframework.context.support.ClassPathXmlApplicationContext refresh WARNING: Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'myEmf' defined in class path resource [resources/applicationContext.xml]: Invocation of init method failed; nested exception is javax.persistence.PersistenceException: [PersistenceUnit: default] Unable to build Hibernate SessionFactory Exception breakpoint: AbstractApplicationContext.java:576, org.springframework.beans.factory.BeanCreationException, Error creating bean with name 'myEmf' defined in class path resource [resources/applicationContext.xml]: Invocation of init method failed

I am at a loss for what to do...

Some ideas for restructuring the website to improve documentation:

Instead of listing config parameters under client->command instead create a config subsection, where we document the command and list how to set it in the different clients, and which commands it applies to. This would aid in linking to docs (at the moment we have to figure out the users client to figure out which copy to link to), and would reduce a lot of duplication.

We currently also have the commands listed with a vague overview, but the details of how to use that command, and what config options exist to configure it, exist under the client pages (and arent visible from the overview)
Example: https://flywaydb.org/documentation/command/migrate gives no info on how to actually run a migrate. https://flywaydb.org/documentation/commandline/migrate does, but is not linked from the sidebar, you have to just know it exists.
Instead we should combine the vague overview and the config list, and show and example for how to run that migrate in each client.

These 2 things would vastly improve the docs imo.

The docs suggests there;s an environment variable called FLYWAY_EDITION, where -pro can be set (for example)

But the environment variables doc page doesn’t list that as an option: https://flywaydb.org/documentation/envvars

(and it’s not in the conf > flyway.conf file)

Like the docker.io docs

Seems creating functions with flyway in vertica works fine if the statement starts with "CREATE FUNCTION" but if you use the support "CREATE OR REPLACE FUNCTION" then the script breaks on the firs ";" and fails to migrate.

Example of code :
CREATE OR REPLACE FUNCTION default_to_hello(x VARCHAR) RETURN VARCHAR
AS BEGIN
-- The body of a SQL function in Vertica must be in the form 'RETURN expression'
RETURN (CASE WHEN (x IS NOT NULL) THEN x ELSE 'Hello' END);
END;

Error Produced:

Current version of schema "public": 2
Migrating schema "public" to version 3 - test
ERROR: Migration of schema "public" to version 3 failed! Please restore backups and roll back database and code!
ERROR:

Migration V3__test.sql failed

SQL State : 42601
Error Code : 4856
Message : [Vertica]VJDBC ERROR: Syntax error at or near "EOL"
Location : /opt/flywaydb/sql/V3__test.sql (/opt/flywaydb/sql/V3__test.sql)
Line : 1
Statement : CREATE or replace FUNCTION default_to_hello(x VARCHAR) RETURN VARCHAR
AS BEGIN
-- The body of a SQL function in Vertica must be in the form 'RETURN expression'
RETURN (CASE WHEN (x IS NOT NULL) THEN x ELSE 'Hello' END)

Code run in vertica :

dbadmin=> CREATE or replace FUNCTION default_to_hello(x VARCHAR) RETURN VARCHAR
dbadmin-> AS BEGIN
dbadmin-> -- The body of a SQL function in Vertica must be in the form 'RETURN expression'
dbadmin-> RETURN (CASE WHEN (x IS NOT NULL) THEN x ELSE 'Hello' END);
dbadmin-> END;
CREATE FUNCTION
dbadmin=> select default_to_hello('Working');

default_to_hello

Working
(1 row)

dbadmin=> select default_to_hello(null);

default_to_hello

Hello
(1 row)

going here:
https://bintray.com/artifact/download/business/maven/flyway-commandline-3.2.1-macosx-x64.tar.gz

results in a 401

Got error:

> Error occurred while executing flywayInfo
  Missing required JDBC URL. Unable to create DataSource!

Worked for me:

flyway {
  url = 'jdbc:mysql://localhost:3306/my_project'
  user = 'root'
  password = ''
  schemas = ['my_project']
  locations = ['filesystem:sql']
  sqlMigrationPrefix = ''
}

There should be a prompt confirming flyway clean before it is run (with a flag to skip the confirmation), because while the documentation clearly points to the fact that you shouldn't run this in production, documentation is not continuously read while working with production. Another option would be to rename the command flyway drop. But, at the end of the day, it's just too easy to run this command.

It would be nice to be able to view the docs for each version instead of only the most recent.

As per 5.0 release notes:
"Important note for EnterpriseDB, Vertica, SolidDB, Phoenix and Greenplum: Support for these databases has been kept back and will be integrated later in the Flyway 5.0 series. You can keep using Flyway 4.2.0 until then."

Which 5.0 release have these been integrated into?

Hi,

not sure if this is the right issue tracker, but it seemed more appropriate than the main flyway one.

It seems the flyway repository located at http://flywaydb.org/repo referenced in the SBT documentation is down, the URL just leads to the main site.

This is a tracking issue for a number of designer suggested improvements:

Front Page

• Update download chart to 2020
• Replace simple, focused, powerful with
  • Simple to use. Flyway lets you regain control of your migrations with ease
  • Solves one problem well. Flyway migrates your database, so you don't have to worry about it anymore
  • Made for continuous delivery. Releases have never been this easy
  • Remove call to action buttons
• Remove version number from main call to action button
• Drop download, release notes, apache v2 license links and make works on bigger (Though maybe add a download button to push users to the download/buy page?)
• Add how does flyway work secondary buttons next to get started with buttons

Download Page

• Add download button in community column, this should link to a page that prompts for choosing the version (move the bottom of this page to it)
• Left align choose your flyway edition heading
• Move price to top of features table
• Add links to all features to further explanation
• Add button to get started to thank you for downloading page that links direct to cli tutorial

Getting Started - How

• Figure out how to explain classpath for non-java users
• Introduce and link to schema history table docs
• Update picture to replace schema_version with schema_history_table

First Steps - CLI

• Explain what an h2 database is
• Replace foobar with mydatabase
• For users who dont want to use h2, add some details about how to determine url/user/password for their own database
• Add more sample urls to URL config param page
• Point out double underscore for migration name

General

• Seperate CLI download page from docs page (instead of just having it be the top part of the index)

On the Flyway Plugin Development page, one of the images does not load:

The structure of the link looks consistent in the repository with other documentation images.

There is a typo on the getting started page:

"Read to get started? Take a 5 minute tutorial:"

Should read:

"Ready to get started? Take a 5 minute tutorial:"

in flyway 6 several breaking changes were introduced (mostly in flyway/flyway#2218).
For example, sqlMigrationSuffix is no longer accpeted, now it's plural sqlMigrationSuffixes.
Such breaking changes should be documented in the release notes.