3 messages in com.mysql.lists.plusplusRe: fixed length char handling/declar...
FromSent OnAttachments
Shigeya Suzuki16 Jul 2006 06:06 
Warren Young18 Jul 2006 03:31 
Shigeya Suzuki19 Jul 2006 09:55 
Subject:Re: fixed length char handling/declaration by SSQL
From:Shigeya Suzuki (shig@wide.ad.jp)
Date:07/19/2006 09:55:11 AM
List:com.mysql.lists.plusplus

Warren Young wrote:

From the Wishlist:

o 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.

Fix by co-opting the first template query version of each of these functions, as it takes a single SQLString, which contains a length and doesn't care about nulls. Also add an overload taking a const char* and a length parameter, for cases where the user doesn't want to convert their data to a std::string variant. Make the latter the actual terminus of the call chain, as it's cheaper to convert from SQLString to const char* than the reverse.

Implement that feature, and I believe your problem will be solved. Or, wait for someone else to get to it. It should be in the next release, whenever that happens.

OK. Since my time at this moment is very limited, I will write some wrapper class to handle IPv6 address (it's two long longs).

I've tried to write DB independent C++ SQL DB libraries for three times in last 12 years and always not satisfied with result..

Again from the Wishlist:

o Abstract all uses of MySQL C API functions into a database driver class with a generic interface. This is a step towards database-independence....

In other words, we just haven't gotten to making MySQL++ database independent yet. If you want to tackle this, too, I'd only caution that it will break the ABI to do this right. That means we can't accept patches for this until we're ready to do v3.0, at the earliest.

That's good, but again, due to limitation of spare time at this moment, I will not work on this.

Hope I can contribute something in future.

Thank you!

shigeya