问题描述:
周末遇见这样的大坑真是让人不爽啊。
这是一个2008年就有人踩过的坑 —— http://bugs.mysql.com/bug.php?id=40673。
DBI的rows()方法以及do()方法返回的affected rows,都没有返回affected行数,而是返回匹配条件的行数。
这意味着,当我们连接MySQL连续执行3次”UPDATE table1 SET col1=’a’ WHERE id=1 LIMIT 1″时,3次DBI都会返回1。
但PHP和C的API都是头一次返回1,后面2次都返回0的。
我对DBI的好感度一下子就下降了10!
解决方法:
还是求助CPAN找到了解答 —— https://rt.cpan.org/Public/Bug/Display.html?id=58595。
解决这个问题需要在new出DBI的时候显式关闭mysql_client_found_rows选项,像下面这样。
1
2
3
|
my
$
dbh
=
DBI
->
connect
(
$
mysql_data_source
,
$
mysql_username
,
$
mysql_passwd
,
{
'RaiseError'
=
>
1
,
'mysql_client_found_rows'
=
>
0
,
}
)
;
|
事后反思:
这个mysql_client_found_rows选项居然没有记录到DBI的文档里。
所以今天我才能在Google上看到如此多的抱怨,咒骂,吐槽和争执,从2008一直延续到2013。
DBI这么长的文档居然都还有遗漏事项,且给开发人员带来了如此大的困扰。
我想,现在程序外配文档的做法是值得再考虑的。
只要是分离就会有同步的问题,那由此带来的痛苦就总会源源不绝。
转自:http://blog.yikuyiku.com/?p=4072
收 藏