Author: wyoung
Date: Thu Aug 9 20:02:43 2007
New Revision: 1740
URL: http://svn.gna.org/viewcvs/mysqlpp?rev=1740&view=rev
Log:
Fixed a bug in Query::store() and use() introduced during the 2.2 series
that would overly agressively reset the success_ flag on receiving an
empty result set. No doubt it went unnoticed this long because a) those
that use Query::success() instead of looking at the return value of the
function or using exceptions are in the minority; and b) those that call
store() and use() with queries that can return empty result sets are a
smaller minority. The union of these minorities are the only ones
affected.
Modified:
trunk/lib/query.cpp
Modified: trunk/lib/query.cpp
URL:
http://svn.gna.org/viewcvs/mysqlpp/trunk/lib/query.cpp?rev=1740&r1=1739&r2=1740&view=diff
==============================================================================
--- trunk/lib/query.cpp (original)
+++ trunk/lib/query.cpp Thu Aug 9 20:02:43 2007
@@ -144,6 +144,7 @@
copacetic_ = !mysql_real_query(&conn_->mysql_, str, len);
unlock();
+
if (copacetic_) {
return ResNSel(conn_);
}
@@ -430,31 +431,29 @@
}
}
-
+ MYSQL_RES* res = 0;
if (copacetic_ = !mysql_real_query(&conn_->mysql_, str, len)) {
- MYSQL_RES* res = mysql_store_result(&conn_->mysql_);
- if (res) {
- unlock();
- return Result(res, throw_exceptions());
- }
- else {
- copacetic_ = false;
- }
- }
+ res = mysql_store_result(&conn_->mysql_);
+ }
+
unlock();
- // One of the MySQL API calls failed, but it's not an error if we
- // just get an empty result set. It happens when store()ing a query
- // that doesn't always return results. While it's better to use
- // exec*() in that situation, it's legal to call store() instead,
- // and sometimes you have no choice. For example, if the SQL comes
- // from outside the program so you can't predict whether there will
- // be results.
- if (conn_->errnum() && throw_exceptions()) {
- throw BadQuery(error());
- }
- else {
- return Result();
+ if (res) {
+ return Result(res, throw_exceptions());
+ }
+ else {
+ // Either result set is empty (which is copacetic), or there
+ // was a problem returning the result set (which is not). If
+ // caller knows the result set will be empty (e.g. query is
+ // INSERT, DELETE...) it should call exec{ute}() instead, but
+ // there are good reasons for it to be unable to predict this.
+ copacetic_ = mysql_field_count(&conn_->mysql_) == 0;
+ if (copacetic_ || !throw_exceptions()) {
+ return Result();
+ }
+ else {
+ throw BadQuery(error());
+ }
}
}
@@ -572,30 +571,29 @@
}
}
+ MYSQL_RES* res = 0;
if (copacetic_ = !mysql_real_query(&conn_->mysql_, str, len)) {
- MYSQL_RES* res = mysql_use_result(&conn_->mysql_);
- if (res) {
- unlock();
- return ResUse(res, conn_, throw_exceptions());
- }
- else {
- copacetic_ = false;
- }
- }
+ res = mysql_use_result(&conn_->mysql_);
+ }
+
unlock();
- // One of the MySQL API calls failed, but it's not an error if we
- // just get an empty result set. It happens when use()ing a query
- // that doesn't always return results. While it's better to use
- // exec*() in that situation, it's legal to call use() instead, and
- // sometimes you have no choice. For example, if the SQL comes
- // from outside the program so you can't predict whether there will
- // be results.
- if (conn_->errnum() && throw_exceptions()) {
- throw BadQuery(error());
- }
- else {
- return ResUse();
+ if (res) {
+ return ResUse(res, conn_, throw_exceptions());
+ }
+ else {
+ // Either result set is empty (which is copacetic), or there
+ // was a problem returning the result set (which is not). If
+ // caller knows the result set will be empty (e.g. query is
+ // INSERT, DELETE...) it should call exec{ute}() instead, but
+ // there are good reasons for it to be unable to predict this.
+ copacetic_ = mysql_field_count(&conn_->mysql_) == 0;
+ if (copacetic_ || !throw_exceptions()) {
+ return ResUse();
+ }
+ else {
+ throw BadQuery(error());
+ }
}
}
_______________________________________________
Mysqlpp-commits mailing list
[email protected]
https://mail.gna.org/listinfo/mysqlpp-commits
