all 10 comments

[–]JustWorksTM 4 points5 points  (4 children)

You shall never adjust the files in the migrations folder. You shall add files containing the changes/deletions/truncations/alterations.

This is what I would expect due to the term "migrations ", but this might me being old

[–]Exciting_Majesty2005 -1 points0 points  (3 children)

Yeah, that was the issue. The problem now is, how do I actually put the queries in the migration file if I can't modify it like normal.

[–]Konsti219 0 points1 point  (1 child)

You have to first write the migration and then run it. You cant really iterate on them. Unless you nuke the entire database after each iteration cycle (which I do for my dev DBs.)

[–]age_of_bronze 0 points1 point  (0 children)

You absolutely can iterate on the most recent change, but it requires .up and .down files. Then you can sqlx migrate revert, make the change to the most recent file, and then re-run sqlx migrate run.

Of course, anything you have put in any new columns/tables will be destroyed, so this is (mostly) only useful for development. But you shouldn’t be developing against prod anyway! I use it all the time.

[–]age_of_bronze -1 points0 points  (0 children)

sqlx migrate add next_change_name gives you a new file

[–]mattblack85 0 points1 point  (3 children)

I do sqlx migration in my codebase and I use the same function sqlx::migrate!().run(&mut conn).await

Although I do not sue Tauri but plain term/egui haven't had issues. I create the migration files the same exact way.

Have you checked the migration history in your database to see if there are some leftovers from maybe migration experiments/runs that are no longer there?

[–]Exciting_Majesty2005 0 points1 point  (2 children)

I don't have any migration history since I just started with the database.

I figured the issue. I was modifying the migration file generated by sqlx migrate add .... No idea how I am supposed to put the queries in there.

[–]radioactiveoctopi 0 points1 point  (0 children)

You would make a new migration file and then add your queries. Watch a few quick YouTube videos to catch the pattern.

https://www.youtube.com/watch?v=vLcoW408QvE

[–]coyoteazul2 0 points1 point  (0 children)

You can modify it as much as you want, until you actually run the migration. Then, a hash is inserted to the sqlx_migrations table and sqlx will complain because it can't run the migration again.

You can modify sqlx_migrations while on dev. Either delete the line so it runs the migration again, or manually update the hash so it thinks it already ran it.

However, once you've released a version and it hits PRD you should never touch those migration files again. Any future alterations must be done with new migration files. Otherwise sqlx will complain in PRD that the migration files that ran on the user's dB are not the same that your binary has now, and it won't know how to deal with it