Allow specifying default migrator for tests

[Kobzol]

I have found these related issues/pull requests

Slightly related:

• Allow different migration strategies for sqlx::test - "before all tests" vs "before each test" #2514
• Make sqlx::test not take minutes to run migrations every time #4133

Description

I have a crate with ~30 migrations and ~350 #[sqlx::test] tests. Recompiling tests of this crate is quite slow, and I tracked a large fraction of that to sqlx loading and most importantly generating all the migrations for each test into the final generated output. rustc struggles to deal with all that code quickly.

For reference, time cargo test --no-run after a no-op change (touch file file) takes ~7.3s, and the output of cargo expand --lib --tests as 32 MiB (!).

If I remove the migrations (and keep only one), the rebuild time goes to ~5s, and the cargo expand output has ~5 MiB.

This can be resolved by embedding the migrations in the crate just once:

#[cfg(test)]
static MIGRATOR: sqlx::migrate::Migrator = sqlx::migrate!();

and then referencintg this migrator in all tests e.g. #[sqlx::test(migrator = "crate::MIGRATOR")]. This works, but it is annoying to specify the migrator in all tests, and it can be easily forgotten, which causes tests to become slower with each such test.

Prefered solution

Allow specifying a default migrator in sqlx.toml, something like this:

[test]
default_migrator = "crate::MIGRATOR"

and then in expand_advanced, if there is a default migrator configured in the config, and the given test did not specify it, we use the default migrator instead.

I'm happy to work on the implementation if you would consider accepting this feature.

Is this a breaking change? Why or why not?

No, the default migrator would only be applied if a new opt-in config option would be used, otherwise the behavior is unchanged.

[abonander]

Your proposed solution is reasonable, though may have a small footgun in that the path needs to be valid in all tests that use #[sqlx::test], so it may need re-exports or duplicate definitions in certain places to put it at the right path.

I'd love to make this work automatically somehow, but I can't imagine how that could work without using some pretty fragile hacks.

[Kobzol]

Maybe the user could optionally specify a table with a different path per crate? Assuming that proc macros can check from which crate they were invoked 🤔