Hello internals@,
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:
- 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. - 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. - 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.
Regards,
Calvin
*
Hi Calvin!
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