List:MySQL++« Previous MessageNext Message »
From:Kevin Regan Date:February 10 2006 7:11pm
Subject:RE: Strange result from query::execute()?
View as plain text  
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@stripped] 
Sent: Friday, February 10, 2006 11:00 AM
To: MySQL++ Mailing List
Subject: Re: Strange result from query::execute()?

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.

-- 
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:    http://lists.mysql.com/plusplus?unsub=1

Thread
Strange result from query::execute()?Kevin Regan10 Feb
  • RE: Strange result from query::execute()?Kevin Regan10 Feb
  • Re: Strange result from query::execute()?Warren Young10 Feb
RE: Strange result from query::execute()?Kevin Regan10 Feb