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

In multiple managed schema scenario, if one of the schemas already exists, no other schema is created #1328

kovacevicm opened this issue Jun 2, 2016 · 4 comments


Copy link

@kovacevicm kovacevicm commented Jun 2, 2016

What version of Flyway are you using?


What database are you using (type & version)?

Postgresql 9.4

What operating system are you using?


What did you do?

I'm spinning up a new Postgres database for Spring Boot app integration test purposes. (each time tests are run)
Flyway is configured to manage two schemas

  enabled: true
  schemas: notifications,public

In DbSchemas.create():70 schema public is recognised as already existing, and create() returns without creating notifications schema.

What did you expect to see?

Missing schemas created.

What did you see instead?

Missing schema was not created.

Copy link

@axelfontaine axelfontaine commented Jun 2, 2016

This currently works as designed, but I am not opposed to revisit this decision in the future.

Copy link

@felixge felixge commented Nov 20, 2017

I just got caught by this by surprise as well. I can work around it easily, but it'd be nice if flyway was either always creating all missing schemas or not create any schemas at all (requiring this to be done in the migration files manually).

Right now I always need to do this in my migration files when adding a new schema:


But this leads to the following warning when setting up a new machine:

WARNING: DB: schema "my_new_schema" already exists, skipping (SQL State: 42P06 - Error Code: 0)

Upgrading an existing machine doesn't produce this warning because flyway doesn't create the schema right now.

Copy link

@htto htto commented Nov 27, 2018

This currently works as designed

Care to elaborate on that a bit? For MySQL, I find it difficult to believe it is intended to try and fail creation of the history table ten(!) times in a row, if the containing schema doesn't exist but one of the the others does.

Also what is the plan of resolving this old issue? The workaround for injecting the schema for the history table beforehand isn't that nice either.

@juliahayward juliahayward removed this from the Flyway 6.0.0 milestone Jul 31, 2019
@juliahayward juliahayward added this to the Flyway 6.1.0 milestone Jul 31, 2019
Copy link

@MikielAgutu MikielAgutu commented Oct 16, 2019

Related to #2277

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

7 participants