search

libsql / sqlalchemy-libsql

SQLAchemy dialect for libSQL
MIT License
20 stars 6 forks source link

add support for create_async_engine #7

Open douglasmdev opened 11 months ago

douglasmdev commented 11 months ago

This PR works as a "v0" for adding async support. We're simply adding a libsql dialect that's flagged as async without modifying the dbapi itself. As it stands, this PR will allow usage of the create_async_engine api: https://docs.sqlalchemy.org/en/20/orm/extensions/asyncio.html#sqlalchemy.ext.asyncio.create_async_engine

ncecere commented 7 months ago

Is there any movement on this ?

tpougy commented 3 months ago

@douglasmdev, first of all thank you for your contribution to the project. I'm not the maintainer of this repo but I'm using the package in an async project and I had a question about your PR.

In the disclaimer inside the file “sqlalchemy_libsql/libsql_async.py” you say: “While this dialect allows for async_engine compatibility with libsql, the dbapi remains synchronous”.

I'm using Litestar as a framework to implement a CRUD api in python that would connect via async sqlalchemy with a libsql DB (turso). In my project all routes are async.

Although I have a background in computer engineering, I'm struggling to fully understand the short and medium term impacts that using sqlalchemy-libsql could have on system performance since the DBAPI remains sync.

Considering this sync characteristic of the libsql DBAPI, wouldn't my routes that interact with the DB, although declared as async, work synchronously? What's confusing me about all this is that all my sqlalchemy interactions with the database are called with await so that it's possible to return fetched data or a success/error code to the client. Wouldn't that make the interactions synchronous anyway? If so, there would be no impact on the DBAPI being synced, right?