The easiest scenario is when you point Flyway to an empty database.
It will try to
locate its metadata table. As the database is empty, Flyway won't find it and will
create it instead.
You now have a database with a single empty table called SCHEMA_VERSION
by default:
This table will be used to track the state of the database.
Immediately afterwards Flyway will begin scanning the filesystem or the classpath of the application for migrations. They can be written in either Sql or Java.
The migrations are then sorted based on their version number and applied in order:
As each migration gets applied, the metadata table is updated accordingly:
installed_rank | version | description | type | script | checksum | installed_by | installed_on | execution_time | success |
---|---|---|---|---|---|---|---|---|---|
1 | 1 | Initial Setup | SQL | V1__Initial_Setup.sql | 1996767037 | axel | 2016-02-04 22:23:00.0 | 546 | true |
2 | 2 | First Changes | SQL | V2__First_Changes.sql | 1279644856 | axel | 2016-02-06 09:18:00.0 | 127 | true |
With the metadata and the initial state in place, we can now talk about migrating to newer versions.
Flyway will once again scan the filesystem or the classpath of the application for migrations. The migrations are
checked against
the metadata table. If their version number is lower or equal to the one of the version marked as current, they
are ignored.
The remaining migrations are the pending migrations: available,
but not applied.
They are then sorted by version number and executed in order:
The metadata table is updated accordingly:
installed_rank | version | description | type | script | checksum | installed_by | installed_on | execution_time | success |
---|---|---|---|---|---|---|---|---|---|
1 | 1 | Initial Setup | SQL | V1__Initial_Setup.sql | 1996767037 | axel | 546 | true | |
2 | 2 | First Changes | SQL | V2__First_Changes.sql | 1279644856 | axel | 2016-02-06 09:18:00.0 | 127 | true |
3 | 2.1 | Refactoring | JDBC | V2_1__Refactoring | axel | 2016-02-10 17:45:05.4 | 251 | true |
And that's it! Every time the need to evolve the database arises, whether structure (DDL) or reference data (DML), simply create a new migration with a version number higher than the current one. The next time Flyway starts, it will find it and upgrade the database accordingly.