weiznich

5 ms·

1.
by weiznich 2y ago
It doesn't even work for all dynamic where clauses, but only for such that can lead to a fixed number of combinations. This approach doesn't work for dynamic API's that let users combination column + filters as required, whic
2.
by weiznich 2y ago
Again the assumption that no change in `schema_version` means that the observed schema stayed the same is not correct. One counter example is creating a temporary table. This doesn't increase the `schema_version` flag, but it allows yo
3.
by weiznich 2y ago
As this claim comes up quite often I have a set of examples I typically ask these people to provide. So far I've got so response, maybe you can point out how you would implement one or more of the following queries using `sqlx::query!`
4.
by weiznich 2y ago
As pointed out in the parent comment you do not need to update this pragma to create a mismatch between the expected schema and the actual schema. The point here is that this is not a sufficient safe way to ensure the schema is what you act
5.
by weiznich 2y ago
I just want to point out that reading the value of this pragma is not the same as verifying that the schema hasn't change, as this does not guard you against manual modifications of either the value of the pragma (after all I can just
6.
by weiznich 2y ago
> So is this the expected workflow? It's impossible to write what is the expected workflow, because that heavily depends on your requirements. Overall there is certain functionality that exists in diesel and that can be combined in
7.
by weiznich 2y ago
> As for async, my primary concern for that was to make sure you minimise blocking code calls in your futures. Even if there weren't many performance gains to be made from Diesel itself being async but having database calls marked a
8.
by weiznich 2y ago
That depends on the workflow. The query checking is based on the information in your `schema.rs` file. That file is usually generated via a CLI tool provided as part of diesel in your local development workflow. It's generally assumed
9.
by weiznich 2y ago
Please note that up until today an async rust database library does not give you any measurable performance advantage compared to a sync database library. In addition to that it won't even matter for most applications as they don'
10.
by weiznich 2y ago
Please note that this comparison is outdated since at least 2 years, given that diesel-async exists for more than 2 years now and this page completely forgets to mention it.
11.
by weiznich 2y ago
> Also sqlx. The guarantees provides by sqlx are less strong than what's provided by diesel due to the fact that sqlx needs to know the complete query statically at compile time. This excludes dynamic constructs like `IN` expression
12.
by weiznich 2y ago
You get the same safety guarantees with diesel by using the [`embed_migration!`]( https://docs.diesel.rs/2.2.x/diesel_migrations/macro.embed_m... ) macro and running your applications on startup. Diesel decouples th
13.
by weiznich 4y ago
Please reach out on the diesel discussion forum[1] about the lacking dev experience. I'm happy to discuss these issues and potential solutions there. [1] https://github.com/diesel-rs/diesel/discussions
14.
by weiznich 4y ago
Diesel maintainer here. So first of all we are aware of the sometimes bad error message and we are working on solutions. There is already an unstable feature flag that improves some error messages and the next diesel release will include ad
15.
by weiznich 4y ago
Just using a transaction that will be rolled back after each test case is exactly what diesel suggests. There is a separate function for this on diesels connection trait[1] [1]: https://docs.diesel.rs/2.0.x/diesel/
16.
by weiznich 5y ago
At least for diesel that's not true anymore. I've build a async connection implementation that will published alongside the next major release. See https://github.com/weiznich/diesel_async for details