Proposal idea: PDO Provider

[Rasmus Schultz]

Okay, so nobody wants an update of PDO, or, at least, nobody wants to design or implement PDO 2.0.

Meanwhile, we have almost universal problems with PDO that we might be able to address by introducing a PDO provider of sorts.

The problems I have in mind are:

1. PDO instances connect immediately - putting a provider in front of it enables constructor injection without eagerly opening the actual connection.

2. PDO instances do not provide access to their constructor values - hostname, dbname etc. are lost at creation.

There are dozens of PDO extensions in the wild - they're almost universally unusable, since most frameworks invent their own variation of this.

Standardizing on a provider, as opposed to some sort of PDO extension, enables existing PDO extensions to coexist peacefully with this.

What I'm suggesting is a fairly unopinionated model facet, essentially describing the constructor arguments you can give to the PDO constructor.

Something along the lines of this:

interface PDOProvider

{

    public function getPDO(): PDO;

    public function getProtocol(): string; // e.g. "mysql", "pgsql", etc.

    public function getSetting(): array; // e.g. ["host"=>"localhost", "dbname"=>"testdb"]

    public function getUsername(): string;

    public function getAttributes(): array; // e.g. [PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8"]

}

Note that getPassword() is omitted for security reasons. (it isn't technically a liability in itself - you have the password in clear text if you were able to pass it to the PDO constructor, but it doesn't seem useful, and I suspect a lot of people will "perceive" this as a potential security liability.)

This is just a quick draft.

Any thoughts?

[Girgias]

Hello,

I don't really understand why the provider should give access to the Username of the PDO instance to be created, would this be for debugging purposes?

I maybe would also prefer to have specific methods for retrieving the hostname, port, database name, charset, etc.

But this will probably render the interface quite complicated so I'm also fine as it is currently.

Best regards

George P. Banyard

--
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 php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/a7a8240b-fb8b-4f1a-bfc1-ae2943964830%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rasmus Schultz]

Yes, the username is for debugging purposes.

Adding accessors for individual settings like hostname, port, dbname and charset, we'd start to venture into abstraction territory - for example, it isn't a given that there's any port-number in the settings, and each protocol has it's own default port-number, so implementations start to duplicate the internals of PDO drivers, etc. and things start to get opinionated... which I was trying to avoid.

If we did add accessors like getPort() we'd need a discussion about the return-type - e.g. int, which burdens implementations with knowing the default port-number of every protocol-type, versus e.g. int|null, which burdens consumers if they need to know the port-number.

Having thought more about this during the day though, I'm not sure if this idea is solid though.

If it's supposed to help with debugging, you'd want to see the connection information in an object that occurs in the stack-trace somewhere - this won't give you that.

Maybe that's one reason there are so many PDO extensions out there and very few (if any?) providers as proposed here.

I'm not sure, maybe this idea is a stop-gap at best?

If we really want to improve on the current situation, maybe we do need a full replacement interface for PDO, which would require a very lengthy process to create a design that doesn't hide or break any PDO features...

You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/1_V02TlJXBQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAFPFaMLNmH5PbMDeFvD%2BV%3DPCE308YB%2BK1ZChugu%2BeokeW%2BtP4Q%40mail.gmail.com.

[Larry Garfield]

I guess I'm unclear what the use case is. What would a consumer of this
object do with it, and how, and why?

Show us some code examples of how you'd use it in practice.

--Larry Garfield

[Jaroslav Kuba]

I have recently issue with PDO library too but a little different story. I want to have simple as possible access to database server and PDO object is about preparing PDO statement, binding values, executing query, fetching result, closing cursor and catching exceptions. That code contains a lot of lines and I repeatedly write the same codes many times. Then I decide to create a very simple interface for database access where I put query, parameters and it returns result directly in one method call. I've created two projects first contains interfaces https://github.com/twoleds/database and second is implementation with PDO extension https://github.com/twoleds/database-pdo. The implementation contains lazy initialization of PDO connection. For my use case it works pretty good but it hides a lot of features from PDO which I don't need for my application. I'm planning to create another implementation / decorator for debugging which will dump information about executed queries in database. It's only for inspiration I don't recommend use this projects. Maybe it will be nice to have something similar and simple as psr standard.

Dňa pondelok, 28. januára 2019 13:30:49 UTC+1 Rasmus Schultz napísal(-a):

[Rasmus Schultz]

For the record, I also have connection, statement and result abstractions in my own PDO wrapper:

https://github.com/mindplay-dk/sql/tree/master/src/framework

I didn't care to mention this, because the problem I'm trying to solve is solely a dependency problem.

I wouldn't want a wrapper or layer around PDO as a "standard" - it would be too opinionated, and standardizing something like this could (literally) take years.

Specifically, I don't want to hide (or abstract) PDO itself - only the creation of it - because the PDO instance itself could very well be a dependency I need to pass to some library that doesn't support the provider, which you could still use in (for example) a DI container, to directly bootstrap PDO when required.

I just want what PDO should have had in the first place: an abstraction in front of the actual (PDO) connection instance that reflects the values it was initialized with, without automatically opening the connection.

This could maybe be solved with an actual extension of PDO, like aura/sql does - e.g. by extracting a public interface:

https://github.com/auraphp/Aura.Sql/blob/3.x/src/PdoInterface.php

And adding some new methods like the ones I drafted for the provider, to reflect initialization values.

Probably a PDOFactoryInterface would also be required then, so we can standardize how a PdoInterface instance gets constructed - since the PDO class itself obviously wouldn't implement the PDOInterface.

If that's the approach, what I *wouldn't* want is added functionality, like what aura/sql does here:

https://github.com/auraphp/Aura.Sql/blob/3.x/src/ExtendedPdoInterface.php

Again, this gets too opinionated, and I'm only looking to abstract to the point of solving the dependency problems.

This is definitely a much bigger problem scope though, as we would likely also need a PDOStatementInterface to complete the abstraction - I'm not entirely sure that's even possible, and not really sure where this would end... I suspect merely having a statement abstraction would very likely trigger long discussions about ways to improve it over PDO's native interface...

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/1_V02TlJXBQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/cf1f896d-06e0-4eaa-b742-6779d977185a%40googlegroups.com.