Really great to see more than one viable async database library aside from asyncpg.
Thank you!!
Building a Django driver for Psycopg 3
11–20 of 26 posts
Re: Building a Django driver for Psycopg 3
#12I was wondering what the major changes between psycopg2 and psycopg3 were. Found a post from the maintainer here: https://www.varrazzo.com/blog/2020/03/06/thinking-psycopg3/
Main takeaways:
- Asyncio from the ground up
- Uses PQexecParams to do database-side escaping and interpolation
- ContextManager and transaction api improvements for
- Python only fallback if the C extension fails to build
Re: Building a Django driver for Psycopg 3
#13I was wondering what the major changes between psycopg2 and psycopg3 were. Found a post from the maintainer here: https://www.varrazzo.com/blog/2020/03/06/thinking-psycopg3/ Main takeaways: - Asyncio from the ground up - Uses PQexecParams to do database-side escaping and interpolation - ContextManager and transaction api improvements for - Python only fallback if the C extension fails to build
YES to this last!! Musl cross deploy can be annoying otherwise - any tips on building Alpine Linux ?
Re: Building a Django driver for Psycopg 3
#14The example syntax for connection handling is perfect. The footgun of not releasing the connection (especially from pools at the end of the with) is real. And the concepts are different (block of transactions vs normal with file xxx. )
with connect(DSN) as conn:
with conn.transaction():
do_something()
with conn.transaction():
do_something_nested()
with conn.transaction() as tx:
do_something_else()
# we were just testing and we don't really want to do this
tx.rollback()
# and here the connection is closed
Re: Building a Django driver for Psycopg 3
#15I was wondering what the major changes between psycopg2 and psycopg3 were. Found a post from the maintainer here: https://www.varrazzo.com/blog/2020/03/06/thinking-psycopg3/ Main takeaways: - Asyncio from the ground up - Uses PQexecParams to do database-side escaping and interpolation - ContextManager and transaction api improvements for - Python only fallback if the C extension fails to build
> - Asyncio from the ground up
> - Python only fallback if the C extension fails to build
These two are really big! The former, for first-party async support, making it much easier to use with async frameworks.
The latter would make it much easier to ship in containers. I assume it's still better use the C version, for performance reasons.
Re: Building a Django driver for Psycopg 3
#16The example syntax for connection handling is perfect. The footgun of not releasing the connection (especially from pools at the end of the with) is real. And the concepts are different (block of transactions vs normal with file xxx. ) with connect(DSN) as conn: with conn.transaction(): do_something() with conn.transaction(): do_something_nested() with conn.transaction() as tx: do_something_else() # we were just test…
Ruh roh I have some code to fix. :sweat_smile:
Re: Building a Django driver for Psycopg 3
#17I was wondering what the major changes between psycopg2 and psycopg3 were. Found a post from the maintainer here: https://www.varrazzo.com/blog/2020/03/06/thinking-psycopg3/ Main takeaways: - Asyncio from the ground up - Uses PQexecParams to do database-side escaping and interpolation - ContextManager and transaction api improvements for - Python only fallback if the C extension fails to build
That last one is great if it’s hidden behind a flag and some loud messages saying “failed to build, consider using —-python-only with performance limitation.”
Otherwise it’s going to be a source of mysterious performance issues with a single error message hidden somewhere in your CI or other logs.
Re: Building a Django driver for Psycopg 3
#18The example syntax for connection handling is perfect. The footgun of not releasing the connection (especially from pools at the end of the with) is real. And the concepts are different (block of transactions vs normal with file xxx. ) with connect(DSN) as conn: with conn.transaction(): do_something() with conn.transaction(): do_something_nested() with conn.transaction() as tx: do_something_else() # we were just test…
For what it's worth, using context managers for this kind of thing is pretty much standard nowadays, and not supporting this behavior feels jarring and archaic.
Re: Building a Django driver for Psycopg 3
#19Really great to see more than one viable async database library aside from asyncpg. Thank you!!
What isn't viable about Aiopg?
(Assuming you are only talking about Postgres libraries.)
Maybe it's somewhat obsolete now that Psycopg itself supports async. I think most people used Asyncpg because it's "easier" and supports useful stuff like connection pools.
Re: Building a Django driver for Psycopg 3
#20A somebody who first started using DB code from Perl, and later learned Python, I always wondered by Python doesn't have a general database interface like DBI in Perl. In Perl, all the database specific modules have a DBI backend, and all the higher-level modules (django-like frameworks, for example) rely on DBI. In Python, SQLAlchemy has its own psycopg and cmysql integrations, and does django, and likely several ot…
Creator of sqlalchemy here, I came from the perl DBI and JDBC worlds prior to starting python. We have pep 249, but it's generally a very loose spec, projects that implement it basically choose how much they want to follow or not follow it, and then with the introduction of asyncio people are walking away from the whole thing as the spec has not evolved pretty much at all for many years. At the top is that there is n…
I had the chance to complain to Guido once about wanting a better DBAPI, especially on the subject of result set metadata/typing (looking at you, pysqlite with your worthless cursor.description)
This was after a mypy/typing talk, so highly tangentially relevant I suppose.
While it's not perfect, I think JDBC really is the gold standard, and I wish there was a DBAPI spec that was a bit closer to that, especially something with proper prepared statements. I haven't used database/sql in Go but it seems okay too.
Thanks for sqlalchemy - it has become the de facto DBAPI in many projects I've worked on.