------_=_NextPart_001_01C62E6A.61063BC8
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Should the following have different results?

...
std::string s =3D "SET AUTOCOMMIT=3D1";
query.execute(s.c_str());
query.execute(s);

The first succeeds. The seconds throws an exception with the value =
"Query was empty." Looking at the code, the first call goes to =
Query::execute(const char*). However, the second uses a "parms" version =
of execute.

Is this expected behavior? From the library user's perspective, it =
seems confusing.

--Kevin

------_=_NextPart_001_01C62E6A.61063BC8--

------_=_NextPart_001_01C62E6A.AC88B790
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This is with v2.0.7.

--Kevin

-----Original Message-----
From: Kevin Regan [mailto:k.regan (AT) f5 (DOT) com]
Sent: Fri 2/10/2006 9:49 AM
To: plusplus (AT) lists (DOT) mysql.com
Subject: Strange result from query::execute()?
=20

Should the following have different results?

...
std::string s =3D "SET AUTOCOMMIT=3D1";
query.execute(s.c_str());
query.execute(s);

The first succeeds. The seconds throws an exception with the value =
"Query was empty." Looking at the code, the first call goes to =
Query::execute(const char*). However, the second uses a "parms" version =
of execute.

Is this expected behavior? From the library user's perspective, it =
seems confusing.

--Kevin


------_=_NextPart_001_01C62E6A.AC88B790--

Kevin Regan wrote:
It's a known weakness in the library's current design. If we added an
overload for execute(const std::string&), we'd run into ambiguous
conversion problems. This Wishlist item is on point, if you'd like to
tackle it:

Currently, all overloads for Query's execute(), store()
and use() methods eventually call the const char*
version, which does the actual work of executing the query.
This rules out query strings with embedded nulls, as you're
likely to get with BLOB columns. Also, it means MySQL++
must scan the string for length in a few places. The C API
isn't limited in this way if you use mysql_real_query(),
but you need an accurate length value to call it. We could
get that length with binary data if the end of the call
chain were a std::string overload, but we can't do that
easily because each of these functions has a version taking
a SQLString (a subclass of std:string) for template queries.

One way around this is to add a parallel set of functions
(e.g. do_execute(), or execute_(), or some such) that take
a single std::string, which are the new terminus of the call
chain. Reimplement const char* versions in terms of these.

Another way is to rename the template query versions (e.g. to
execute_tq()) to avoid the overload conflict. With that
done, we can use C API functions like mysql_real_query(),
which can take binary data.

Yet another way is to add a length parameter to the call
chain end functions.

And finally, we may be able to co-opt the first template
query version of each of these functions, as it takes a
single SQLString.

If done right, the change can go into v2.1, as it wouldn't break the
ABI. Otherwise, it'll have to wait for v3.0.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Warren,

Thanks for the info. If I can muster some free time I'll take a crack
at this.

--Kevin

-----Original Message-----
From: Warren Young [mailto:mysqlpp (AT) etr-usa (DOT) com]=20
Sent: Friday, February 10, 2006 11:00 AM
To: MySQL++ Mailing List
Subject: Re: Strange result from query::execute()?

Kevin Regan wrote:
It's a known weakness in the library's current design. If we added an=20
overload for execute(const std::string&), we'd run into ambiguous=20
conversion problems. This Wishlist item is on point, if you'd like to=20
tackle it:

Currently, all overloads for Query's execute(), store()
and use() methods eventually call the const char*
version, which does the actual work of executing the query.
This rules out query strings with embedded nulls, as you're
likely to get with BLOB columns. Also, it means MySQL++
must scan the string for length in a few places. The C API
isn't limited in this way if you use mysql_real_query(),
but you need an accurate length value to call it. We could
get that length with binary data if the end of the call
chain were a std::string overload, but we can't do that
easily because each of these functions has a version taking
a SQLString (a subclass of std:string) for template queries.

One way around this is to add a parallel set of functions
(e.g. do_execute(), or execute_(), or some such) that take
a single std::string, which are the new terminus of the call
chain. Reimplement const char* versions in terms of these.

Another way is to rename the template query versions (e.g. to
execute_tq()) to avoid the overload conflict. With that
done, we can use C API functions like mysql_real_query(),
which can take binary data.

Yet another way is to add a length parameter to the call
chain end functions.

And finally, we may be able to co-opt the first template
query version of each of these functions, as it takes a
single SQLString.

If done right, the change can go into v2.1, as it wouldn't break the=20
ABI. Otherwise, it'll have to wait for v3.0.

--=20
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: =
http://lists.mysql.com/plusplus?unsu...) f5 (DOT) com


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw