New PSR for providing PDO connections (PdoProviderInterface)

[maximegosselin]

There is no standard contract for passing a PDO connection between libraries, and passing \PDO directly surrenders control over the connection lifecycle.

Goal

Provide a minimal interface that decouples PDO connection consumption from connection lifecycle management, and enables interoperability between libraries that need a connection and those that manage one.

Background

https://maximegosselin.com/posts/proposing-a-psr-for-pdo-providers/

[Jean85]

Hi @maximegosselin, thank you for drafting your proposal. To make this go further, I suggest you to look at our PSR workflow, which this proposal should follow.

I would suggest to reach out to whomever should adopt this interface (i.e. Doctrine) to have them onboard, which would raise the probability of this being accepted.

I'll switch this to draft for now.

[samdark]

Does it have to be bound to PDO?

[maximegosselin]

Does it have to be bound to PDO?

Could you please elaborate? I'm not sure what "bound to PDO" means in this context. Are you suggesting the interface should return a more generic type, or something else entirely?

[KorvinSzanto]

I'm not really sure I see the benefit here as stated. In general, a library that consumes a PDO connection can already be interoperable by simply accepting the connection itself via DI.

Can you be more specific about why hinting on something like PdoProviderInterface rather than just the connection itself is beneficial? Is it just to reconnect if the connection has timed out?

[maximegosselin]

To provide supporting evidence for this proposal, I've put together a research repository that demonstrates how 10 popular PHP database libraries handle PDO connections in practice:

https://github.com/maximegosselin/pdo-provider-research

It covers three scenarios for each library:

1. creating a connection from configuration
2. accepting an existing PDO object
3. exposing the internal PDO instance.

The consistent pattern across library types supports the case for a standard PdoProviderInterface.

Libraries covered:

• atlas/orm
• aura/sql
• cakephp/database
• clancats/hydrahon
• doctrine/dbal
• envms/fluentpdo
• illuminate/database
• nette/database
• paragonie/easydb
• php-db/phpdb

[maximegosselin]

I'm not really sure I see the benefit here as stated. In general, a library that consumes a PDO connection can already be interoperable by simply accepting the connection itself via DI.

Can you be more specific about why hinting on something like PdoProviderInterface rather than just the connection itself is beneficial? Is it just to reconnect if the connection has timed out?

@KorvinSzanto That's a fair point. Accepting \PDO directly via DI works but it ties the consumer to an already-open connection and gives it no control over the lifecycle. With PdoProviderInterface, the provider decides when and how to open the connection.

A concrete example: Doctrine DBAL has lazy connection support built in. With a standard PdoProviderInterface, you could pass a Doctrine DBAL provider directly into FluentPDO (instead of a \PDO), and FluentPDO would get a connection only when it actually runs a query. Today, there is no standard way to do that. Each library manages its own connection and there is no common contract to bridge them.

[Crell]

@maximegosselin Please keep the discussion on the list, not in the PR. That way there's only one place folks need to follow.

[maximegosselin]

Sure! ---> https://groups.google.com/g/php-fig/c/bqkysNgw9k4