How to mark a migration as applied?

[mbrevda]

When adopting drizzle to an existing project, the workflow seems to be:

1. run introspect:pg to generate the schema
2. run the generated migration so that it's marked as applied in the db

Often the migration cannot be re-run as it contains commands that cannot be reapplied (e.g. re-creating a primary key).

So how can this migration be marked as applied?

[capaj]

this is very easy in prisma as they rely on the migration name as primary key for identifying the migration. Too bad in drizzle there is a hash and no easy way to calculate the hash from the CLI

[jwatte]

That is not a particularly helpful comment, because we're using drizzle, not prisma.
I think using the hash is safer because otherwise who knows what version of the file named 0099_upgrade_stuff.sql was actually applied?
But, we need to mark a particular migration as applied when it requires manual fix-up; for example, when altering primary keys in postgres, which drizzle migrations fail to do correctly.

[dnishiyama]

Has anyone seen any update on this? We're running into the same issue

[btmnk]

I tested around a bit and it seems like the hash is not used at all. When you change the created_at timestamps to your when timestamps from the _journal.json drizzle does not try to apply these migrations. But I still wonder what the hash is then used for..

(I've only tested this with a single migration so I'm not sure what happens with multiple migrations)

[benmarg]

Thanks found this helpful. Guessing the hash is probably deprecated since they can just use the timestamp instead

[seanparkross]

+1
Especially if switching from push to migrate for an existing database.

The way I got around this was to move the SQL out of the first 0000_name_name.sql file and replace with SELECT 1;. Let that migration process on deploy to create the migration table and the first migration table entry in the database and then replace the SQL in my file and deploy again. It doesn't try to do it again because it's going on timestamps not the hash. The hash is totally wrong now though. No way to fix it. But whatever. I'm sure that will mess me up later somehow. 🫠

[kenerwin88]

You sir are a genius, thank you for posting this.

[Dudeonyx]

For me I just comment out the entire SQL, run the migration then uncomment it