So for v3, no casting will help? Seems like I must use SQLQueryParams,
or rearrange my parameters.
Am I the only one who's been tripped up by this (twice now)? Using
store(...) is very convenient and when composing my query I'm thinking
about the query, not overloads to store(). I can see arguments for
using it, but it sure seems like a developer trap that is only detected
at runtime.
Do you always talk about yourself in third-person? :-)
-----Original Message-----
From: Warren Young [mailto:mysqlpp@stripped]
Sent: Tuesday, August 04, 2009 9:42 PM
To: plusplus@stripped
Subject: Re: Question about store() override
On Aug 4, 2009, at 5:19 AM, Jim Wallace wrote:
> Warren suggested casting the second parameter to mysqlpp::String
No, he suggested casting it to SQLString, a v2 class which became
SQLTypeAdapter in v3, not String. (You will find this pointed out in
the breakages chapter of the user manual.)
This does fix it; I just tested it.
The problem happens because there is a store(const char*, int)
overload, which is for taking a string with a length, needed to allow
query strings with embedded null characters. Without this, MySQL++
wouldn't support BLOBs naturally. (It didn't always exist, back in
the bad old days, and BLOBs were therefore a pain to use at the time.)
If you cast just the first parameter to STA, that doesn't help because
it can convert right back to const char*. Casting the second forces
the compiler to use the store(const STA&, const STA&) overload.
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:
http://lists.mysql.com/plusplus?unsub=1