Hello Maxime, Larry et al... I am reading this with interest but I wonder if this is actually a problem looking for a solution or the other way around.
If the use case is: Multiple frameworks share a DB connection object then my solution would be to maintain the created DB Connection (PDO or otherwise) in a caching factory, injector with instance reuse or whatever and simply inject it into multiple framework DBALs. But I begin to understand this is not the complete intent here. Is Pdo actually a good name? A couple of the DB drivers I deal with aren't really PDO-native. What do I win if the interface is limited to providing the DB object and then I am left with the bare thing? Also in my experience having multiple managers on the same handle isn't a good idea. DB connections are not stateless. Advanced work with relational DBs includes atomic transactions - I don't want a stranger with his own needs interact with my transaction in progress. There are cases which might benefit but it's a headache to debug once things go wrong. Just saying. On Thu, Mar 12, 2026 at 5:40 PM Maxime Gosselin <[email protected]> wrote: > Hi Larry (and all), > > Sorry for the longer-than-usual reply, but I think a more complete answer > now will help avoid misunderstandings down the road. > > > *== On the PSR-20 parallel ==* > > I want to address your point about PSR-20 first, because I think there is > a fundamental misunderstanding about what this interface is meant to share. > > You described *PdoProviderInterface* as "a way to extract one service > dependency from another service." That is not the intended use. The > parallel with PSR-20 actually holds: just as every service that needs the > current time is injected with a ClockInterface and calls now() repeatedly, > every service that needs a database connection would be injected with a > *PdoProviderInterface* and calls getConnection() each time it needs one. > What is shared between services is the interface, not a \PDO instance. The > provider behind the interface decides what getConnection() returns. It > could be a lazy singleton, a reconnected instance, or a pooled connection. > That is exactly the point. > > > *== On why PdoProviderInterface and not PdoInterface ==* > > This also addresses a question raised by Alexander Makarov in the PR "Does > it have to be bound to PDO?" ( > https://github.com/php-fig/fig-standards/pull/1348#issuecomment-4040272736 > ) > > The short answer is yes, and deliberately so. Early in my thinking I > considered a PdoInterface that would mirror \PDO's full API. That approach > touches PHP internals and RFC territory. It would also tightly couple the > standard to PDO's own method signatures, which is a moving target. A single > getConnection(): \PDO keeps the contract minimal and stable. \PDO is the > only de facto standard for relational database access in PHP. This > interface simply formalizes how you get access to it, not what it exposes. > > > *== The real problem: library authors ==* > > With that in mind, the problem is better described as: a library should be > able to benefit from another library's connection infrastructure without > coupling itself to it. > > If I write a query builder or an event store library, my options today are: > > 1. Accept a raw \PDO -- simple, but I lose lazy-connect, auto-reconnect, > and pooling > 2. Depend on Doctrine DBAL -- I get those benefits, but I force that > dependency on everyone using my library > 3. Ship adapters for Doctrine, Laravel, Nette, etc. -- I get > interoperability, but I maintain N adapters forever > 4. Invent my own contract -- which is what I ended up doing > > *PdoProviderInterface* would be the missing fifth option: depend on a > minimal contract, and let the consuming application plug in whichever DBAL > manages the connection. > > > == Concrete examples from my own work == > > In Backslash PHP (the event sourcing framework I maintain), I had to > invent my own PdoInterface and a PdoProxy wrapper just to support > lazy-connect. A standard interface would have solved that problem. You can > see it here: > > https://backslashphp.github.io/docs/application-setup/defining-services/#configuring-the-pdo-connection > > I also maintain an internal enterprise application (Horizon) that has > grown over the years to include Laravel, Doctrine DBAL for migrations, > FluentPDO for query building, and other components depending on raw PDO. > Each manages or consumes a connection independently. > *PdoProviderInterface* would be the common thread letting all of them > share the same managed connection. I cannot make this codebase public, but > I suspect it is not an unusual situation for applications that have evolved > organically. > > > == Supporting research == > > To support this proposal with more than anecdotes, I put together a > research repository that examines how 10 popular PHP database libraries > handle connection creation, injection, and exposure: > https://github.com/maximegosselin/pdo-provider-research > > It maps out the disparities between libraries and their readiness to adopt > *PdoProviderInterface*. The patterns are consistent enough to suggest the > problem is real, even if the solutions today are fragmented. > > ---------- > > I would be curious to hear from other library authors and from maintainers > of applications that have grown beyond a single DBAL. This might be a > problem that is common but invisible because everyone solves it in > isolation. > > Regards, > Maxime Gosselin > > Le jeu. 12 mars 2026, à 10 h 30, Larry Garfield <[email protected]> > a écrit : > >> 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 >> . >> > -- > 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/CAPhJx--TNnaJY_dYnFKtbf%2BtUu8d%3Dhj83bHLTv-JHX_ZB90ATg%40mail.gmail.com > <https://groups.google.com/d/msgid/php-fig/CAPhJx--TNnaJY_dYnFKtbf%2BtUu8d%3Dhj83bHLTv-JHX_ZB90ATg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAB%2BY%2BEreK3zuLBpFb5x8vc1Jn86EdgzZNpNuPEoXWxFTd_2hKg%40mail.gmail.com.
