~olly/yoyo#60: 
asyncpg support

Is there a possibility for yoyo-migrations to support asyncpg backend?

Status
REPORTED
Submitter
~takeda
Assigned to
No-one
Submitted
3 years ago
Updated
3 years ago
Labels
No labels applied.

~olly 3 years ago

It's not something I have planned, and I'm not really experienced enough with async to know what would be involved in adding this. I'd be happy to discuss the idea in more detail though if someone was thinking of contributing an implementation.

~takeda 3 years ago

I can work on creating this, although I'm not yet familar with the code base. Since yoyo doesn't really need to perform its work asynchronously, it could still just invoke operations synchronously through asyncio.run().

The biggest reason for adding this driver is so applications that want to use it don't have to depend on asyncpg and psycopg2.

~olly 3 years ago

Thanks! A backend that isolates any async work with asyncio.run sounds ideal.

~takeda 3 years ago

After looking more into it, seems like the proper way would be actually to make the migration code async. That way adding other async drivers would be easier in the future, and the sync code simply just wouldn't be using await. This would require me to update existing drivers (probably the only change would be to change some "def" to "async def". The synchronous driver should continue to work, and basically not using "await" will equate to a synchronous call. Does that sound reasonable? What I initially proposed will make the async driver ugly looking, and any future ones will still need to do the same amount of work.

~takeda 3 years ago

Sorry, the last sentence supposed to be, the prior one was confusing: "What I initially proposed would make the async driver ugly looking, and any future async ones would still need to do the same amount of work. That's why I think the current approach is better"

~olly 3 years ago

I see what you mean about making it easier for future async drivers. Makes sense.

But I'm not sure what you mean by making the migration code async – how far up the stack would this go?

At the top of the stack, the external api shouldn't change for synchronous clients. And at the other end, migrations steps defined as python functions shouldn't need to know about async (unless they use an async driver of course). Inbetween, well, I'm happy if it can be as simple as changing def to async def in a few places :)

Register here or Log in to comment, or comment via email.