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 common thing with stored procedures
> 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 >= 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.
--
Christoph M. Becker
