search

nkonev / r2dbc-migrate

R2DBC database migration library
https://nkonev.name/post/136
Apache License 2.0
99 stars 9 forks source link

File checksum validation doesn't happen #5

Open abhi2495 opened 4 years ago

abhi2495 commented 4 years ago

If any changes are made to an already migrated sql script file and run again, there are no logs ( neither error / nor any info) for this. Seems like the library has the following logic : For a file named like V1__xxxxxx.sql , during migration, it parses the version , which is 1 here and checks in migrations table whether the record with id=1 is present. If it's there, it does nothing, else executes the script.

Thus even if we rename the file after __ (double underscore) keeping the version same, or change it's content, it simply ignores.

This behaviour is quite different from Flyway where checksum computation happens for every script.

Another probable missing feature:

For a multi-tenant microservice, if we choose schema-per-tenant approach (i.e same database server, different schemas for different tenants), then using this library how are we supposed to run migration scripts (creating the tables etc ) for every schema during application startup ? If I am not wrong, the ConnectionFactory requires mentioning schema.

nkonev commented 4 years ago

Seems like the library has the following logic : For a file named like V1__xxxxxx.sql , during migration, it parses the version , which is 1 here and checks in migrations table whether the record with id=1 is present. If it's there, it does nothing, else executes the script.

Thus even if we rename the file after __ (double underscore) keeping the version same, or change it's content, it simply ignores.

yes.

I think actually there are two issues:

  1. calculate and validate checksums in order to prevent modifying already applied migrations
  2. support schemas
  1. looks complex to implement. I know Liquibase and Flyway have this, but is it common practice - to occasionally change already applied migrations ? I believe that the code review prevents this. In addition, in case when we have applied migrations V1 and V3, Liquibase allows to insert V2 between them. Anyway, PRs are welcome.
  2. to solve this - I think to make migrator's schema and table names configurable.
nkonev commented 4 years ago
  1. has been done in 1.3.0