Using the connection for migrations about diesel_async HOT 8 CLOSED

Thanks for opening this bug report. I'm aware of this, but it's good to have an explicit issue for this. I do not consider that to be a huge problem for now, as migrations are mostly run on application start. That's a place where it's perfectly fine to just use a blocking method.
I might spend some time to look into ways for fixing this in the future, after the diesel 2.0 release and an initial diesel_async release. (Just to be explicit about that: This takes likely some time, I do not expect to find time for this in the next few months)

from diesel_async.

Hi,

I created this quickly by just copying the standard diesel migrations and making the strings public. It's not composable in any way.
There might be many pitfalls and shortcomings in this solution and we've only used it with postgres but it's been working fine for us this far.

As I understand it it's fine to copy the code as long as I keep the MIT-license.

@weiznich If my understanding regarding the licenses is wrong or there's any other issue with the naming or anything, let me know and I'll correct it. I'm just dropping a link here so that anyone who wants quick migrations can use it.

from diesel_async.

One thing to note about the blocking method is it required libpq headers to be present, which is annoying if you bet on async and don't need it otherwise.

How would you approach the implementation of this? I presume this will require a rewrite of the diesel_migrations harness to decouple the execution from the control logic somehow. Or would it be better to rewrite the whole harness to be async with the same design but async fns?

from diesel_async.

@nicrgren It's fine to fork and change that code on your own. I just do not want to do that for diesel-async as well, as I do not want to maintain that much duplicated code.

from diesel_async.

I honestly must say that I do currently not have an idea how to implement this in a composable way. What I can say: It will require quite a bit of design work, which is something I personally do not have the capacity for at the moment.

If your main goal is to remove the dependency on libpq it seems like easier short term solution to just write a rust-postgres based sync connection implementation as third party crate. That shouldn't be to hard based on the existing diesel-async AsyncPgConnection based on tokio-postgres (as that already shows how to do all the type conversions).

from diesel_async.

I am staring at #100 but I don't understand how that fixes this issue. My problem is that I have a AsyncPgConnection and I need to call run_pending_migrations. It seems that with AsyncConnectionWrapper I can take a database URL and turn that into a AsyncConnectionWrapper::<DbConnection>, but that's not useful since I don't have the URL... the connection has long been established (by Rocket, which magically picks up the URL from the config file or environment variable or whatever), I just need to somehow call migrations on it. Help would be appreciated :)

Also, the docs mention a DbConnection type that I cannot find anywhere.

from diesel_async.

It expects you to create a new connection either based on the connection url or based on an existing connection via a From impl. The later is only available in an unreleased version yet. I cannot comment on how to do that based on rockets setup as I don't use rocket myself. It might be worth to ask that in their support channels. That written: There is currently no other built-in way that allows you to apply migrations via diesel_migrations at application startup. It's also likely that this won't change anytime soon as diesel_migrations API expects a sync diesel connection. Hopefully that helps at least to understand what's possible and what's not possible.

Also, the docs mention a DbConnection type that I cannot find anywhere.

DbConnection can by any type that implements AsyncConnection.

from diesel_async.

Yeah I think that From instance would suffice. Good to hear this will be resolved in a future version. :)

For now I switched back to sync diesel.

from diesel_async.