Question

We have a database in production that already has a good number of rows in the “user” table. Consider the following statement from the flyway website:

If you have an existing database that has not been filled by Flyway
this is the way to go:

• Create an initial migration script that will recreate your current
  state and give it a low version number.
• Use flyway:init to create the metadata table and set this script as the current version.

I’d like to use flyway to manage my schema and various constants in the database, but I don’t want V1__Base_version.sql to contain the account information for our current production users, especially considering it’s stored in SCM. If I understand these instructions correctly though, I would need the ability to “recreate [my] current state” with V1__Base_version.sql.

So would creating an initial migration with just the schema and the constants work okay? Or do the databases on our workstations need to match those in production 100%?

Answer 1

You are correct. The init command is there to mark the production database with a version.

The initial migration you create (with the structure of your PROD db) is for the other environments. It will never run on PROD as its version will be below the init version. It will however align all environments so that subsequent migrations can be applied equally across all of them.