Building a Django driver for Psycopg 3
psycopg.org
Building a Django driver for Psycopg 3
1–10 of 26 posts
Re: Building a Django driver for Psycopg 3
#2Thanks for your hard work in making the transition from psycopg2 to psycopg3 as simple and painless as possible, Daniele!
Re: Building a Django driver for Psycopg 3
#3Just a huge thank you to Daniele for developing and maintaining psycopg! The article shows the level of professionalism and care that goes into this project. Using Django to test implementation is a genius idea. I can't wait to try the new version in a few of my projects, the changes (especially server-side parameters binding) sound great.
Re: Building a Django driver for Psycopg 3
#4Casually building a django db backend as an acceptance test. Nice work and great write up!
I had déjà vu reading the section on bind parameters in aggregate queries. The oracle backend had a similar issue that was fixed/hacked by comparing values and grouping them into named parameters. https://code.djangoproject.com/ticket/27632
Re: Building a Django driver for Psycopg 3
#5A 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 other frameworks.
(Java has a similar standard, with JDBC, I believe; though I have never used it, so I might be misunderstanding something here).
Re: Building a Django driver for Psycopg 3
#6A 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…
There is https://www.python.org/dev/peps/pep-0249/ . I suppose part of the issue is that there is probably deviation from the standard and lots of extensions. I imagine that the standard means there is a lot of shared code between the different connectors though.
Re: Building a Django driver for Psycopg 3
#7A 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…
JDBC exists but I honestly think it's a mistake. Higher-level frameworks still end up with a bunch of special cases for handling different lower-level implementations, and meanwhile a lot of functionality gets stuck behind the lowest common denominator interface that JDBC is (e.g. it took forever to get any kind of async support even when both the things above and the things below JDBC were doing great at it).
Re: Building a Django driver for Psycopg 3
#8A 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…
JDBC exists but I honestly think it's a mistake. Higher-level frameworks still end up with a bunch of special cases for handling different lower-level implementations, and meanwhile a lot of functionality gets stuck behind the lowest common denominator interface that JDBC is (e.g. it took forever to get any kind of async support even when both the things above and the things below JDBC were doing great at it).
> e.g. it took forever to get any kind of async support even when both the things above and the things below JDBC were doing great at it
is there even support for async jdbc? I tought they dropped the idea ? (https://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/20...). The reasoning is stupid because async drivers is not only about threading and more about i/o, but w/e.
Re: Building a Django driver for Psycopg 3
#9A 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…
There is https://www.python.org/dev/peps/pep-0249/ . I suppose part of the issue is that there is probably deviation from the standard and lots of extensions. I imagine that the standard means there is a lot of shared code between the different connectors though.
As far as I know, there is zero or close to zero shared code.
PEP 249 is great to have, and it's nice to at least have a starting point for learning a new database connector library.
But not all database connector libraries implement the specification. One well-known library [0] explicitly and deliberately violates the spec with no spec-compliant "escape hatch". Also the style of passing parameters as a single sequence (e.g. list or tuple) tends to be a newbie trap, and having 4 different placeholder styles can be annoying.
That said, there are ODBC connector libraries [1] if you really do need a uniform interface. But at that point you might be better off with the SQLAlchemy "Core" query builder [2].
[0]: Asyncpg, https://magicstack.github.io/asyncpg/
Re: Building a Django driver for Psycopg 3
#10A 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 no actual library in which these drivers all need to bind towards as is the case with DBI and JDBC.
All of that said the reality is that databases are so different in how they define client interactions you're going to have these problems with either approach. The transparency of Python allows it to be ultimately easier to work through these issues, though I've always wished there was a better pep249 story.