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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
