From: Warren Young
Date: July 18 2006 10:31am
Subject: Re: fixed length char handling/declaration by SSQL
List-Archive: http://lists.mysql.com/plusplus/5829
Message-Id: <44BCB88F.5090208@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Shigeya Suzuki wrote:
> 
> I understand that it is possible to fetch binary data using
> 'fetch_lengths' function (according to ML), but since I love power of
> SSQLS, I prefer using it if possible. Or, prefer to write or modify some
> template to achieve this. I tried to use string but string seems to be
> not working well.

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.

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