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... On Mon, Mar 18, 2019 at 6:00 PM Jaroslav Kuba <[email protected]> wrote: > 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): >> >> 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? >> >> -- > 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 > [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/cf1f896d-06e0-4eaa-b742-6779d977185a%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/cf1f896d-06e0-4eaa-b742-6779d977185a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADqTB_hyOFNDQyu%3DuuThWQNpNXg622d6zg%2BKrd9ERTGHWzbfyg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
