Migrations can be modified without notice

[niklas-e]

Migrations can be modified without notice

[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.

[alenap93]

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

[boehs]

I'm curious what the use case would even be for this? Kysely's value to me as a programmer is to help me avoid unexpected things, but when I change my migration that is absolutely an expected change

[niklas-e]

IMO these are the most important reasons for having integrity checks on your database migrations.

---

1. Ensuring consistency

Checksums ensure that the migration scripts remain unchanged from development to deployment. Any modifications to the scripts after they have been executed in a given environment will be detected, ensuring that all environments (development, testing, staging, production) remain consistent. I.e. Helps in preventing schema drift if scripts are altered or not applied uniformly.

2. Audit trails

Having a reliable checksum system helps maintain an audit trail of all changes applied to the database. This can be crucial for compliance and auditing purposes, as it provides a verifiable history of migrations.

3. Collaboration

In a team environment, multiple developers might work on the database schema simultaneously. Checksums help ensure that everyone is working with the same version of the migration scripts, reducing conflicts and integration issues.

4. Reliable rollbacks

This is not so important for me personally as I usually prefer forward-only migration model. However, if a migration fails or causes issues, checksums can help ensure that rollbacks are executed correctly by verifying that the scripts being rolled back are the same as the ones initially run.

---

To summarize, I think it's all about maintaining high standards of database integrity, ensuring reliable deployments and minimizing risks associated with schema changes.