Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flyway schema creation issue on Oracle 12.2 DB with password policy enabled #1943

TimoTHa opened this issue Mar 2, 2018 · 4 comments


Copy link

@TimoTHa TimoTHa commented Mar 2, 2018

Which version and edition of Flyway are you using?

5.0.7, Community Edition

If this is not the latest version, can you reproduce the issue with the latest one as well?

(Many bugs are fixed in newer releases and upgrading will often resolve the issue)

Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)


Which database are you using (type & version)?

Oracle database

Which operating system are you using?

Oracle Linux 7.3 (database host)

Windows 10 EE (Flyway command line host)

What did you do?

(Please include the content causing the issue, any relevant configuration settings, the SQL statement that failed (if relevant) and the command you ran.)

Running "flyway migrate" command on an existing Oracle database instance with the password policy enabled (mininum characters 8), and where target schema does not yet exist.

My Flyway configuration file:

Sample Flyway configuration file


What did you expect to see?

Flyway creating the user/schema successfully.

What did you see instead?

Unable to create schema "FOODEV"

SQL State : 99999
Error Code : 28003
Message : ORA-28003: password verification for the specified password failed
ORA-20001: Password length less than 8

Copy link

@axelfontaine axelfontaine commented Mar 2, 2018

Why exactly do you feel this is a Flyway issue?

Copy link

@TimoTHa TimoTHa commented Mar 2, 2018

Thanks Axel.

Two reasons:

  1. Oracle database 12.2 version provides a set of functions that you can use to manage the complexity of passwords.

On enterprise level, it is quite common to use these, or customize them as per the organization security requirements.

  1. Not sure if I'm looking at the correct source code file, but I feel it is hardcoded to "flyway". In my opinion, it should be at least configurable parameter.

Copy link

@axelfontaine axelfontaine commented Mar 4, 2018

Thanks for the link. The first step we could do, could be moving from flyway to FFllyywwaayy00!! which should be compliant with all predefined policies. This doesn't fully handle the case of custom policies, but it should be sufficient for the vast vast majority of the cases. What do you think?

Copy link

@TimoTHa TimoTHa commented Mar 5, 2018

Thanks Axel for the reply. Yes, more complex default password (like your proposed one) would be good as a quick fix for the issue.

axelfontaine added a commit to flyway/ that referenced this issue Mar 6, 2018
dohrayme pushed a commit to dohrayme/flyway that referenced this issue Feb 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants