No migrations to apply

[rust-db]

No migrations to apply

[johnsom]

This caught me for a minute as well. I just added a build dependency on cargo-emit:

[build-dependencies]
cargo-emit = "0.1.1"

And a build.rs

use cargo_emit::rerun_if_changed;

cargo_emit::rerun_if_changed!(
    "migrations",
);

[Bravo555]

Okay, seems like I have managed to reproduce issue on my end.

1. Delete the database so that it's recreated from scratch.
2. Have two migration files in migrations directory: V1__initial.sql and --V2_secondary.sql (-- so that the migration won't be run).
3. Run the program with RUST_LOG=info cargo run. The first migration is correctly applied.
4. Remove the prefix from the name of second migration (so now it reads V2__secondary.sql, so that it should be applied).
5. Upon running of the program, the secondary migration is not applied.
6. Change the contents of the .rs file, so that the next cargo run recompiles the project.
7. Upon recompiling, the secondary migration is now correctly detected and applied.

What I also noticed is that if i change the name of migration so that it's no longer applicable (V2__secondary.sql -> --V2_secondary.sql) the project gets recompiled. If i do that the other way around, the project no longer recompiles and its in an invalid state, when the second migration should be picked up, but isn't.

So, in conclusion, based on that, I see that the state of the migrations directory is updated at compile time. When a valid migration file gets renamed so that it's no longer valid, the project is correctly recompiled and the invalid migration will not be ran.
However, if an invalid migration file is renamed so that it is valid, or a new migration with a valid filename is created, the change is not picked up. One has to then arbitrarily change something in source code, so that the project will be recompiled, and upon doing so, the migration is only then finally detected and ran.

Could you please try to reproduce the issue on your end?

Also, as to the possible fixes:

• make the project recompile if a new valid migration is created or
• check migrations directory at runtime instead of compile time

[Bravo555]

Similarly to #55 I reckon reflecting the filesystem change would be best achieved by instead of using WalkDir, which works at runtime, using something which acts at compile time?

[jxs]

Hi, thanks! want to submit a patch adressing this issue?

[Bravo555]

Thanks for the response! I would like to but tbh I'm not sure where to start and how would this patch work. I see that something like include_str! is a compiler builtin, so I would need some pointers where to look to implement a viable solution.

[jxs]

so, the reason the macro is used is to bundle the migrations at compile time to the binary using include_str as you mentioned above. We should look for a way to trigger recompilation every time there is a change on the migrations dir

[jxs]

addressed with #170