okay, i need to implement a closure initializing a db. it takes and returns async connection.
is it normal to create *sync* connection to the same db url, do some *sync* migrations, and then return that async connection back.
anyone sees any caveats in this approach?

#postgres #rust

@froufox If you’re doing something sync and it’s blocking, you’re blocking the entire runtime from making any progress (so nothing else is happening at the same time).

But blocking is sometimes necessary, so there are ways to do that. If you’re using Tokio, it’s https://docs.rs/tokio/latest/tokio/task/fn.spawn_blocking.html

spawn_blocking in tokio::task - Rust

Runs the provided closure on a thread where blocking is acceptable.

@bryan hmm, what if i'm running sync migrations from a thread? it depends on implementation i guess, but i'm pretty sure it blocks only this thread and the database, so that is fine.
my goal is to prepare a pool of databases for tests. i use this library for migrations: https://docs.rs/diesel_migrations/latest/diesel_migrations/
diesel_migrations - Rust

Provides functions for maintaining database schema.

@froufox
It never occurred to me to go migrations in sync. Too many checks to make sure everything is done in the right order. I don't know the full case here but just async would be safer and so much easier, I guess?
@jerry1970 diesel library runs migrations in sync by default https://docs.rs/diesel_migrations/latest/diesel_migrations/
it's possible to do it with async connection, but it actually wraps it into sync, because everything should be done in a proper order set by migration files
diesel_migrations - Rust

Provides functions for maintaining database schema.

@froufox Sorry, that's what I meant. I never understood the naming so it keeps confusing me. If things run synchronously, I would say they run next to each other. But yes, migrations should run in order.