Kevin Regan wrote:
> Should the following have different results?
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.
