dvarrazzo

Psycopg 3 supports both sync and async code. Starting from release 3.2, the sync side is automatically generated from the async counterpart. This article explains how it's done, and the workflow used for the initial conversion to autogenerated code and for the regular maintenance.

As someone who is trying to make a living out of free software, I would love to see this project succeeding.

The other remotely similar service, Tidelift, has unacceptable terms and conditions: for the compensation they decide "at [their] sole discretion", "[i]f you do not satisfactorily provide the Services, Tidelift may, at its option and without limitation, (a) require you to immediately re-perform the applicable Service at no additional charge; and/or (b) reduce the fees paid, or due to be paid, to you for the applicable Service in an amount commensurate with the cost to the Subscriber to cover the breach and/or the cost to Tidelift to assist its Subscriber with covering the breach." Quotes taken from the May 2022 "Lifter Agreement", which I was asked to sign for the monthly equivalent of what a professional charges for 30 minutes of work.

I hope that Ringer will prove a real contact point between Free Software professionals and professional users.

This is interesting, thank you for pointing it out. Worth looking if the problems can be fixed the same way in both the adapter (and probably everything else using server-side binding).

There is a mechanism to ensure that there is no unexpected regression. Exposing the PSYCOPG_IMPL env var a program can make sure to obtain a specific implementation and import fails if it's not available. https://www.psycopg.org/psycopg3/docs/api/pq.html

> You can put comments in Python files...

only if the comment pertains to a django feature, not to a schema feature that cannot be expressed in django (e.g. a partial index designed for a specific query).

> You can name your migrations with:

In the example there is a foreign key name, not a migration name. It is persisted in the database, it's not ephemeral like a migration name, for which choosing a meaningful name has only a temporary value.

Just two factual corrections; for the rest our experiences diverge, that's fine.

It also breaks in interesting way: I discovered just today that constants defined on the Model subclass are not available when you use 'get_model()'. I suspect methods wouldn't be accessible either?

My strategy here is to have a staging server where migrations are applied before they can hit production.

As someone else pointed out, migration without CI can be dangerous and difficult to coordinate with deployment.

Hi! Much of the difficulty comes from using blocking libpq calls in psycopg2. I'm thinking to avoid them altogether in psycopg3 and only use async calls with Python in charge of blocking.

Note that you can obtain a similar result in psycopg2 by going in green mode and using select as wait callback (see https://www.psycopg.org/docs/extras.html#psycopg2.extras.wai...). This trick enables for instance stopping long-running queries using ctrl-c.

You can also register a timeout in the server to require to terminate a query after a timeout. I guess they are two complementary approaches. In the first case you don't know the state of the connection anymore: maybe it should be cancelled or discarded, we should work out what to do with it. A server timeout is easier to recover from: just rollback and off you go again.