Flyway usage: what exactly is the migration concept? -

i looked @ flyway samples , documentation , tried understand if useful in environment. following conceptual detail unclear me: how flyway manage changes between database versions? not compare database life-instances (see answer here:can flyway find out , generate migration files datamodel?)

in detail setup looks this: create sql create , insert scripts when coding (automatically , manually). means every version of database represented number of insert/create statements. in world execute these scripts through database tool (sqlplus oracle). each run setup database _from_scratch_ (!).

can put these same scripts 1 1 inside "migration" path of flyway? happens if target database way older last "migration step" did (or flyway did not yet exist when installed)?

update:

i got input flyway user:

it seems each "migration" (version of database) has hand-written sql/java code , contains "updates" previous "migration" of database.

if true, wonder how can used traditional coding technics: in world sql statements generated automatically , contain all database init/create statements, not "updates" previous version. if sql code generator that, wouldn't need tool flyway :-).

your question "how handle db has longer history there migration scripts?" need create v1_ migration/sql script matches/recreates latest db schema. can take blank db have today. create/generate sql script using existing db tools , put in flyways migration directory. (and test v1 using flyway against clean db , see if expect.) http://flywaydb.org/documentation/existing.html

after point in time, later versions must added in work. when decide need new table, in dev environment, write new v*_.sql modifies schema way need it.

this blog goes on situation spring/sql application. https://blog.synyx.de/2012/10/database-migration-using-flyway-and-spring-and-existing-data/