Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117869
MIME-Version: 1.0
References: <CA+kxMuT54_xanhDr2ARceZhK2PrnQpJ0YrfX7rc3Ya4YJsbbpg@mail.gmail.com>
In-Reply-To: <CA+kxMuT54_xanhDr2ARceZhK2PrnQpJ0YrfX7rc3Ya4YJsbbpg@mail.gmail.com>
Date: Tue, 7 Jun 2022 21:29:25 +0200
Message-ID: <CABdc3WoRurE0JDQODaJFDBjAKKWgM6m-NOTnjrdf-yr9Y+Fprg@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ef791505e0e09b9a"
Subject: Re: [PHP-DEV] DB specific PDO subclasses questions.
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--000000000000ef791505e0e09b9a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dan,

pon., 6 cze 2022 o 21:15 Dan Ackroyd <Danack@basereality.com> napisa=C5=82(=
a):

> Hi,
>
> I'm looking at making an RFC for subclassing PDO to expose database
> specific methods in a less magic way, aka implementing what was
> discussed here: https://externals.io/message/100773#100813
>
> I have two questions for people who use the PDO with SQLite or Postgres
>
> 1. Are any of the functions that are specific to those databases
> horribly designed and need changing? As the functions would be 'copied
> across' from where they are now, changes could be made without having
> horrible BC breaks.
>
> That is, are any of these functions horrible to use:
>
> PDO::pgsqlCopyFromArray
> PDO::pgsqlCopyFromFile
> PDO::pgsqlCopyToArray
> PDO::pgsqlCopyToFile
> PDO::pgsqlGetNotify
> PDO::pgsqlGetPid
> PDO::pgsqlLOBCreate
> PDO::pgsqlLOBOpen
> PDO::pgsqlLOBUnlink
>
> SQLIte specific functions:
> PDO::sqliteCreateAggregate
> PDO::sqliteCreateCollation
> PDO::sqliteCreateFunction
>

I admire you for picking up the gauntlet.

Personally, I'm not convinced about these methods being in PDO or in
subclasses at all.
Since PDO is a non-final class someone could already extend it and build
their own functionality around that.
If so, then how would it be solved? Auto-magically extending after let's
say PDOSqlite3 ??

I'd think of extracting driver-specific methods into a Driver / Platform
standalone type like PDODriver / PDOPlatform that is
responsible for all driver-specific methods and attributes to carry.
That one could be fetched from the PDO instance object with a new dedicated
method like "getDriver" / "getPlatform"
whatever, maybe a typed read-only property (that would be an interesting
option).

That way classes like PDOPgSQLDriver or PDOSqlite3Driver might have all the
driver methods and avoid introducing new magic related to inheritance.
There might be a transition period where these could be proxied like
currently in PDO with deprecation error, which allows for a smoother
transition.

Maybe it is just because of using Doctrine DBAL often, but IMO here a
better input might have its contributors.

Best regards,
Micha=C5=82 Marcin Brzuchalski

--000000000000ef791505e0e09b9a--