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 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/cf1f896d-06e0-4eaa-b742-6779d977185a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
