Migrations can be modified without notice

[niklas-e]

Description:

I noticed migrator stores only the migration name into db. Therefore if there's any changes in migrations, you wouldn't notice it in environments where you have ran them already.

Expected behaviour:

Migrator throws an error if the current migration contents do not match already ran migrations.

Possible solution:

This could be potentially solved by adding a checksum of the migration to the migration table and verifying it while running migrations.

[alenap93]

I think that a solution could be a checksum system like liquibase

[Bessonov]

I have used Liquibase in the past, but now in a project I am migrating away from it to Kysely. While I understand the benefits of integrity checks, especially at scale, I am against them or, at least, in favor of having the option to ignore or reset the checks. I have the following reasons:

• The integrity checks ensure only integrity between migration scripts and the metadata of scripts that have already run. If someone modifies data or the structure of data directly, you are still out of luck.
• I assume that past scripts are modified intentionally. For example, if database vendors introduce breaking changes and migrations stop working on newer database versions in integration tests. In my current case, I want to switch to Kysely migrations by running an empty migration and then adding the entire structure from a mysqldump to this migration. Such changes can/should/must be verified in a code review anyway.
• During development, I often modify the database structure manually (especially indexes) and then adjust the migration file accordingly. If the migration has already run, which is almost always the case, then I can't down-up to get a consistent state because the checks say no.
• The checks introduce additional complexity to the code of Kysely.

Therefore, please do not take my reaction to the feature request personally, but as a vote.

[koskimas]

I completely agree with @Bessonov!
We could add the check behind an option (off by default) but that would be tricky since we'd have to migrate the migration tables. I don't think there's a way to do that in a way that'd work on all possible dialects (internal and 3rd party). We'd have to add that to the dialects, making them more complex.