Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113803
To: Calvin Buckley <calvin@cmpct.info>, internals@lists.php.net
References: <ecfba56802e3390bf6dabc1ef785a06896ca13a9.camel@cmpct.info>
Message-ID: <0223e830-4c3e-c49c-7924-4bd48085fa9e@gmx.de>
Date: Fri, 26 Mar 2021 17:30:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <ecfba56802e3390bf6dabc1ef785a06896ca13a9.camel@cmpct.info>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: Improvements to PDO_ODBC
From: cmbecker69@gmx.de ("Christoph M. Becker")

Hi Calvin!

On 26.03.2021 at 15:51, Calvin Buckley wrote:

> I've been looking into improving PDO_ODBC; specifically, bringing it up
> to parity with other drivers, as well as dealing with its quirks. The
> company I work for supports PHP on IBM i, and while we maintain the
> native database drivers for the platform, we (and IBM) have been
> recommending new applications migrate to ODBC.
>
> However, the procedural ODBC driver does have some limitations like no
> in/out parameters (which is a very=C2=A0common thing with stored procedu=
res
> here, unfortunately). PDO_ODBC does support this, but we've noticed
> some issues:

Yes, I think PDO_ODBC is the way to go.  I'd leave ext/odbc alone
regarding new features; I think it's mostly useful to support legacy
code.  The only general downsides of PDO_ODBC I can think of, are issues
with ODBC specific functionality (while PDO offers extension hooks,
these are not well-received for a long time), and the unfortunate fact
that statements are "going_long" (and stay that way), i.e. for column
sizes >=3D 256 use SQLGetData() instead of SQLBindCol() what appears to be
subpar performancewise.

>  * Persistent connections aren't checked, even though the procedural
>    ODBC driver does. This has bitten some of our clients, so we have a
>    patch for them that does impement this; this is PR GH-6805.

That PR looks basically good to me (I've already commented there that
SQL_ATTR_CONNECTION_DEAD is likely the better alternative).

>  * Many of the connection attributes don't seem to be implemented; some
>    of these seem trivial to implement, others less so.
>  * In/out parameters require users to remember to specify size and add
>    one for the null terminator. I'm not familar with other ODBC drivers
>    to call this a driver/platform quirk, PDO_ODBC limitation, or
>    something else, but figuring out a good solution for this would make
>    life easier for users.

TIL.  I don't know about other PDO drivers, but this is something that
should be improved for PDO_ODBC.  I'm not sure about the details, but it
should be doable.

>  * As always, ODBC being a generic abstraction later itself bites us
>    (i.e no standard way to get last ID).
>
> I'm curious if anyone has suggestions for what to be done or how to get
> these done.

Regarding the "how": I think PRs are the way forward.  Some might need
discussion on this ML or even an RFC; some may be considered bug fixes,
and as such should have an accompanying bug ticket, but a PR is a good
start.

=2D-
Christoph M. Becker