I'm getting this error when I try to use the session class with the database driver (only where the database is accessed via ODBC):
"Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[IM001]: Driver does not support this function: driver does not support lastInsertId()' in C:\web\fuel\core\classes\database\pdo\connection.php on line 213"
The example below is for MySQL through ODBC, but this also happens with other databases, e.g. SQL Anywhere.
I see why this is frustrating. The PDO ODBC implementation seems to 'cope' with variability between databases by just ignoring the problem and not implementing any affected methods, such as lastInsertId().
Any workarounds will therefore run into the same root issue: different databases sometimes support different syntax.
Last insert ID syntax for MySQL:
SELECT LAST_INSERT_ID();
Last insert ID syntax for MS SQL Server and Sybase SQL Anywhere:
SELECT @@IDENTITY;
So implementing any SQL-based workaround to replace '$this->_connection->lastInsertId()' in the query() method in classes/database/pdo/connection.pdo would be database-specific.
The only solution I can think of is provide an easy way for applications using the ODBC driver to somehow override the PDO::lastInsertId() method (perhaps this would also apply for PDO::quote() method).
Problem with lastInsertId() is that it's target platform specific.
PDO works around it by defining the interface (PDO::lastInsertId), and leaving it up to the driver to implement it or not. Some do (for example the mysql driver), some have a workaround (for example the pgsql driver), and some don't.
With ODBC the problem becomes even more complex, since ODBC in itself is also an abstraction layer. So you're now facing two abstraction layers, and expect and platform specifics to still work. Which I think you can forget.
The only solution is, as you state, forget about the generic interface, and code up the functions for the different platforms. Which is a lot of work, and possible, but only if you have platform specific drivers.
Which we don't have at the moment (everything goes through the generic PDO driver), but which is possible once we have switched to Cabinet.
No number has been assigned yet, but it will probably be 2.0.
I can't say if that will be the next version, or if there will be a 1.5 (or more) first. It all depends on how quick we can get everything working, and how many changes in 1.5/develop will be made in the meantime.
But if you want you can start using Cabinet now if you want, instead of DB. Drop it in app/vendor, add the cabinet namespace in your app bootstrap (and define it as a PSR namespace), and you're in business. I've already used it this way.
When we introduce Cabinet, we probably keep the current DB API as a legacy package to ease migration.
Donate
