It's always bugged me that DBD::SQLite used the sqlite_get_table() function for data access. This function returns the entire result set as a char ** - i.e. all the data in one long array of strings that I then have to iterate over in calls to $sth->fetch. This works fine, as users of DBD::SQLite will testify, but it means that it uses up lots of memory for large result sets.
It also didn't give me back much information about the results (except the column names and number of rows). In order to get back the data types of the columns (so I could implement $sth->{TYPE}) I'd have to use the sqlite_step() function, which is more DBI-like - an iterator.
Now the downside (after I'd spent hours converting all the code over to using sqlite_step()) is that the tests no longer pass because doing it this way doesn't give me the number of rows coming back from a SELECT. I get the number of rows from an update/insert/delete just fine though.
i.e. I've broken my $rowcount = $dbh->do("SELECT * FROM TABLE");
Now the big question becomes what do I do with these changes?
- Back them out - we can't have backward incompatible changes for what is my most downloaded/used module
- Add lots of extra code to provide the option of one interface or the other
- Just go with it, and inform people who complain about it how to deal with the error