On Wed, Mar 11, 2026, at 1:06 PM, Maxime Gosselin wrote:
> Hi,
>
> I would like to propose a new PSR standardizing how PDO connections are
> provided between libraries.
>
> The problem has two sides. First, passing a \PDO instance directly
> surrenders control over the connection lifecycle: the caller loses the
> ability to control when and how the connection is opened, verified, or
> recreated. Second, there is no standardized contract for passing a
> connection between libraries. Widely-used libraries such as
> doctrine/dbal, illuminate/database, nette/database, and
> cakephp/database each wrap PDO in their own connection object, with no
> common interface.
>
> The proposed interface is intentionally minimal, modeled after PSR-20's
> ClockInterface:
>
> ==========
> namespace Psr\Pdo;
>
> interface PdoProviderInterface
> {
> public function getConnection(): \PDO;
> }
> ==========
>
> Draft PR: https://github.com/php-fig/fig-standards/pull/1348
>
> Background:
> https://maximegosselin.com/posts/proposing-a-psr-for-pdo-providers/
>
> I intend to reach out to the Doctrine DBAL maintainers in the near
> future to gauge their interest.
>
> I am looking for a sponsor and working group members.
>
> Regards,
> Maxime Gosselin
Let me see if I'm following. The original discussion on Reddit was about a
PdoInterface, which would be an Internals question and not something FIG would
be involved in.
Now the proposal has shifted to effectively standardizing the "give me the
connection you're already wrapping" operation that many but not all DBALs
provide. The end goal is to allow an app to use Doctrine, Nette/Database, and
Aura SQL all in one application, all wrapping the same PDO connection object.
(This is fundamentally different than what PSR-20 does, where every service is
injected with a ClockInterface, and the clock is called repeatedly to get a
timestamp value object. That's not at all the same as a way to extract one
service dependency from another service.)
I can somewhat see where that would be beneficial, as opening multiple PDO
connections to the DB in the same request causes all kinds of problems.
However, I am not sure how wide a use case that is. Essentially every
application I've seen has only a single DBAL, or it has a single DBAL plus
legacy code using a raw PDO object. In neither case would being able to share
the connection object between multiple DBALs be relevant.
Right now, this feels more like a theoretical improvement rather than one that
addresses an extant problem in the ecosystem. Does anyone else have different
experience?
--Larry Garfield
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/php-fig/ff37ac84-abf1-4f1d-875e-eb8b7d858c5e%40app.fastmail.com.
