How Flyway works
The easiest scenario is when you point Flyway to an empty database.
最容易的方案是Flyway指向一個空的數據庫。
It will try to locate its metadata table. As the database is empty. Flyway won't find it and will create it instead.
FlyWay將試圖查找它的元數據表。因為數據庫是空的。Flyway找不到它的元數據表，然后就會去創建它的元數據表。
You now have a database with a single empty table called SCHEME_VERSION by default:
現在呢，我們就有一個數據庫，這個數據庫包含一個缺省的空表SCHEME_VERSION :
This table will be used to track the state of the databse.
這張表將被用於監測數據庫的狀態。
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.
緊接着Flyway將開始掃描文件系統或者應用的類路徑進行遷移。這些遷移文件可以是SQL腳本或者是java程序。
The migrations are then sorted besed on their version number and applied in order.
這些遷移文件按照版本號進行排序並且按照這個排序去執行。
As each migration gets applied,the metadata table is updated accordingly:
當每一個遷移文件被執行后，元數據的表就會按照格式進行更新。
schema_version
With the metabata and the initial state in palce,we can now talk about migrating to newer versions.
這樣我們就可以根據元數據和數據庫初始化的狀態，進行數據庫升級了。
Flyway will once agein scan the filesystem or the classpath of the application of the migrations. The migrations are checked against the metadata table. If their version number is lower or equal to the one of the version maked as current, they are ignored.
當Flyway 再次掃描遷移的時候，它就會檢查元數據表中遷移版本，如果要執行的遷移腳本的版本小於或者等於當前版本，Flyway將會忽略，不再重復執行。
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:
元數據的表也會做相應的更新：
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.
這樣的話，每次要做數據庫升級，無論是執行DDL語句還是執行DML語句，所有的解決的問題的就是創建一個高於現在版本的遷移文件。當下一次Flyway開始運行的時候，它將會自動發現升級腳本，執行並且更新元數據表。