You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
calculate and validate checksums in order to prevent modifying already applied migrations
support schemas
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.
to solve this - I think to make migrator's schema and table names configurable.
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 inmigrations
table whether the record withid=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.The text was updated successfully, but these errors were encountered: