Asyncpg: please support SQLAlchemy

Created on 21 Jul 2016  路  14Comments  路  Source: MagicStack/asyncpg

enhancement feedback question wontfix

Most helpful comment

Sorry to comment on a closed issue, found no mailing list to post this - we are working on a simple ORM with the great support of asyncpg and SQLAlchemy core here: https://github.com/fantix/gino. GINO as GINO Is Not ORM, because personally I didn't love ORM magic much, and drove GINO down the way "what you do is what you get" through an object interface. Comments and help are greatly welcome!

All 14 comments

please add SQLAlchemy support

You can use sqlalchemy if you just throw in str() everywhere as sqlalchemy will give you the string format for any statement :wink:

please take a look for aiopg.sa, it would be nice to use asyncpg that way
or as a dbapi driver in sqlalchemy itself. without messy code and manual
str() stuff

@kamikaze @nhumrich We can consider merging a PR that adds SA support, but we aren't interested in implementing it ourselves.

I would go as far as to suggest that SA support be implemented as a separate module on top of asyncpg. We would like to keep the asyncpg API specific to PostgreSQL protocol and features.

then this library is no go. nobody uses psql libs to write sql only code

@kamikaze Psycopg2 and python-mysql don't have ORM mechanisms.
To my knowledge, its are a lot used.
An external library seems to be the right balance for that.

nobody uses psql libs to write sql only code

Sorry, but at least, us. We dropped ORMs 2 years ago, for better efficiency and reduce time to code ;-)
Moreover, we improved our SQL level to write better queries. Win-win effect.

psycopg could be used with SA, and nobody really loves mysql in python
world... and driver sucks. but still usable with SA as i know

I dont like ORM's as much as the next guy but the SA core is really nice for sql statement building.

We can consider merging a PR that adds SA support

I might be willing to do this.

I would go as far as to suggest that SA support be implemented as a separate module on top of asyncpg

Or should I just create my own wrapper library? Would you prefer that stuff be in this library to improve adoption or would you prefer to keep this one more "vanilla"?

Or should I just create my own wrapper library? Would you prefer that stuff be in this library to improve adoption or would you prefer to keep this one more "vanilla"?

Given how much code is in aiopg.sa, it would be preferable to have that in a separate package. If you'd like to pick up the task, aiopg.sa is probably the best place to start.

Not Mine - Wrapper around AsyncPG https://github.com/CanopyTax/asyncpgsa

<-- author of the just mentioned asyncpgsa

Since asyncpgsa package is now available, I think we can close this issue.

Sorry to comment on a closed issue, found no mailing list to post this - we are working on a simple ORM with the great support of asyncpg and SQLAlchemy core here: https://github.com/fantix/gino. GINO as GINO Is Not ORM, because personally I didn't love ORM magic much, and drove GINO down the way "what you do is what you get" through an object interface. Comments and help are greatly welcome!

Was this page helpful?
0 / 5 - 0 ratings