Sqlx: Just build the code without a database or a JSON file

[ip1981]

Is there a way to just skip all machinery and simply build the code without a database or a JSON file?

[izik1]

Yep! You obviously can't use the macros given that they require one of the two of those, but you can use the sqlx::query{, _as, _scalar} methods

[abonander]

The macros require information from the database or JSON file to generate code. It's hard to imagine what code they _could_ generate without any of that data; query!() especially would have trouble since it generates a struct with fields based on the columns of the query. query_as!() could possibly manage but it would have to emit panic!()s internally.

[mkpankov]

Couldn't macros work like methods in the absence of any database data?

[abonander]

That completely negates the guarantees the macros provide. The macros _could_ generate code that compiles, but it would have to panic at runtime because there's not enough information to go on and still have them work as expected.

Making them just work like their function counterparts in this special case would violate the principle of least surprise and make them more difficult to understand and teach, because it would significantly change their semantics. query!() would fall back to requiring dynamic field lookup with .get() and query_as!() would suddenly require its type to implement FromRow which it didn't before.

[mkpankov]

It could be not a silent fallback, but an explicit opt-in. Like, define an environment variable FORCE_IGNORE_VALIDATION.

It's still better because that would allow developer to control validation w/o changes to source code and w/o incurring version control diffs.

The specific situation where it's useful is, you're working on your branch and your database is consistent, then you decide to rebase. Someone made DB-related changes on master. Now to build your code you have to deploy first.

With this change, you would FORCE_IGNORE_VALIDATION after rebase to build first version that could run but would fail at runtime. This is then solved by dropping the database or manually migrating it back to some state from which baked-in migrations are able to run.

So it decreases amount of steps required from "rebase -> deploy master to be able to validate -> build -> deploy your version" to "rebase -> build -> deploy your version".

[jyn514]

This is what sqlx prepare does, no?

[mkpankov]

@jyn514 no

[abonander]

It could only possibly work for query_as!(); I believe query!() would be unable to emit any code that would make it work as expected:

let column = sqlx::query!("select column from my_table").fetch_one(&db).column;

This would _at least_ require generating a struct that has a column field, but we can't possibly know to do that without information from the database.

So it decreases amount of steps required from "rebase -> deploy master to be able to validate -> build -> deploy your version" to "rebase -> build -> deploy your version".

You'd still have to rebuild and redeploy because the version you build right after rebasing won't actually work, will it? It'll be full of emitted panic!()s.