List:MySQL++« Previous MessageNext Message »
From:Shigeya Suzuki Date:July 19 2006 4:55pm
Subject:Re: fixed length char handling/declaration by SSQL
View as plain text  

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
Thread
fixed length char handling/declaration by SSQLShigeya Suzuki16 Jul
  • Re: fixed length char handling/declaration by SSQLWarren Young18 Jul
    • Re: fixed length char handling/declaration by SSQLShigeya Suzuki19 Jul