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

[kovacevicm]

What version of Flyway are you using?

3.1

What database are you using (type & version)?

Postgresql 9.4

What operating system are you using?

Linux

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

flyway:
  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.

[axelfontaine]

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

[felixge]

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:

CREATE SCHEMA IF NOT EXISTS my_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.

[htto]

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.

[MikielAgutu]

Related to #2277