SQLString exists for those places where the library wants to let you
pass any typical C/C++ type, which it will convert automatically to a
SQL-compatible string representation. This is what lets you pass, say,
a mysqlpp::DateTime() to Query::store() to fill in a template query.
MySQL++ currently also provides ColData, which is almost a perfect
inverse: it takes query results in SQL string form, and lets you convert
that easily to typical C/C++ data types.
Do we really need two specialized string types in MySQL++?
The only thing that prevents these two from being complete inverses is
that ColData is purely a constant string, while SQLString derives from
std::string. SQLString is potentially useful as a general purpose
string type, while ColData only accepts new values through its ctors and
MySQL++ doesn't need SQLString to be mutable, though, so the only way
this matters is if someone out there is using SQLString in place of
std::string. Unless that's happening, I can combine these two without
reimplementing std::string or deriving from it. In fact, it would be an
almost trivial extension of the current implementation of ColData in svn.
I don't see why anyone would care to use SQLString this way, but I've
been surprised before...
|• Is anyone using SQLString directly?||Warren Young||11 Aug|