Bug #23974 | DBI::Mysql::column_info() does not return an error when table does not exist | ||
---|---|---|---|
Submitted: | 4 Nov 2006 15:00 | Modified: | 3 Mar 2007 1:37 |
Reporter: | Philip Stoev | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | Connectors: DBD::mysql ( Perl ) | Severity: | S3 (Non-critical) |
Version: | 3.0008_1 | OS: | Linux (Linux) |
Assigned to: | Jim Winstead | CPU Architecture: | Any |
Tags: | column_info |
[4 Nov 2006 15:00]
Philip Stoev
[15 Nov 2006 10:49]
MySQL Verification Team
Thank you for the bug report.
[28 Dec 2006 22:51]
Jim Winstead
I've applied the patch to the DBD::mysql repository, and it will be included in the next release (probably 4.01). Thanks for the bug report and patch.
[21 Feb 2007 23:07]
Tim Bunce
column_info should not return an error if the table doesn't exist. It should just return an empty resultset. The DBI 1.54 spec will clarify this. Please revert the patch.
[22 Feb 2007 0:35]
Philip Stoev
With all due respect, I think the spec should be changed. It is better to return more information to the caller, rather than less -- if column_info returns a reference to an empty array, it would be difficult to know why the call failed, which can happen for various reasons. Also, returning a reference to an empty array will make column_info different from all other calls that return a statement handle. Returning a [] is different from returning an empty result set, and I do not think any code that expects a $sth would behave properly if passed a [].
[22 Feb 2007 0:35]
Philip Stoev
With all due respect, I think the spec should be changed. It is better to return more information to the caller, rather than less -- if column_info returns a reference to an empty array, it would be difficult to know why the call failed, which can happen for various reasons. Also, returning a reference to an empty array will make column_info different from all other calls that return a statement handle. Returning a [] is different from returning an empty result set, and I do not think any code that expects a $sth would behave properly if passed a [].
[22 Feb 2007 0:55]
Tim Bunce
The column_info method is, like the other schema metadata methods, based on ODBC: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcsqlcolumns.a... and should follow that behaviour closely. Note that the result set includes columns for table_name, table_schema etc. That's because it is, in theory, able to return data for multiple tables in one go. It is logically a SELECT statement on the INFORMATION_SCHEMA. The fact it isn't in the current driver is an implementation detail that's influencing your perspective. The column_info method should return an empty result set and not an error for the same reasons that a SELECT that matches no rows should return an empty result set and not an error. Of course if there's an actual _error_ (other than the non-existance of the table) then it should certainly return an error. (I'm not sure why you mentioned returing []. It should never return []. Only undef or a statement handle.)
[22 Feb 2007 1:16]
Philip Stoev
Yes sorry my fault I am getting back a bless( {}, 'DBI::st' ), and not a []. Anyway, can we simply pass any error values from the DESCRIBE query to the DBI::Sponge statement handle that is being created? This way you will get both an empty result set and the original error values.
[22 Feb 2007 1:42]
Tim Bunce
I'd just check for the specific table-not-found error from describe. If you get that error then return an empty result set. If you get any other error then return the error. Otherwise return a resultset for the columns.
[25 Feb 2007 12:54]
Patrick Galbraith
I'm working on a fix for this and plean to put out a release this coming week.
[1 Mar 2007 5:08]
Patrick Galbraith
Will be releasing 4.002 March 1, 2007 to fix this bug.
[3 Mar 2007 1:37]
Jim Winstead
Patrick fixed this in 4.002.