I'm glad I posted this question because I was hoping that you would answer
with more than just how to solve my specific problem. Give a man a
fish.... teach a man to fish... etc.
I think that the specific answer to my problem is to do this:
const mysqlpp::mysql_type_info mysqlTypeInfo = f.type().base_type();
CString strSQLName( mysqlTypeInfo.sql_name() );
Using strSQLName in lieu of the MYSQL_TYPE_XXXX will get met where I need
To your larger point as to why am I doing this, I'll explain what's going
on and maybe you can suggest a better option.
The underlying need is because we have generic code that builds up a query
based on other criteria and later code needs to look at the resultset and
understand the fields that it is looking at. My app uses both ODBC and
mysqlppl. One of our developers (yes, the same one who - inexcusably -
hacked on your code) decided that newer code should be written with
mysqlpp. Hence, I need to support both worlds and sometimes move back and
forth. In this specific instance, I need to populate a CODBCFieldInfo
structure for the field that I fetched using msqlpp. The code in question
needs to map from the MYSQL_TYPE_XXXX to the equivalent SQL_XXXX type.
So back to my original question: If I have the mysqlpp::Field, is there a
better way to do this?
Thanks for your help.
*Director, Development *| Billtrust
Tel: 609.235.0792 | email: jcolman@stripped | Web: www.billtrust.com
Follow us: Twitter <http://www.twitter.com/billtrust>|
LinkedIn <http://www.linkedin.com/company/99112> |
On Fri, Dec 27, 2013 at 5:21 PM, Warren Young <mysqlpp@stripped> wrote:
> On 12/27/2013 11:02, Jake Colman wrote:
>> My former developer added a new method to type_info.h:
> C++ code that makes explicit decisions based on the type of variables is
> usually weak or broken in some way. Casts are similarly a bad sign.
> If you can rewrite this code to avoid the explicit tests or casts, it's
> probably going to be an improvement.
> MySQL++ keeps DB values in the String type up to the point where you use a
> C++ automatic conversion, whereupon it does its best to convert the string
> data into the destination type. If you're using SSQLS, this magic happens
> The only reason I can think of that you might *need* explicit type
> awareness is if your app doesn't know the DB schema in advance, and has to
> figure it out by using MySQL++ as a kind of reflection mechanism.
> If you always know your column data types in advance -- as is sensible
> when using a statically-typed language like C++ -- you should be using
> MySQL++'s built in automatic conversions.
> The point of this method is to allow for getting at the MYSQL_TYPE_XXXX
> If you really must do explicit type testing, it's much better to do it via
> Result::field_type() or String::type(). (String::type() is available
> indirectly via constructions like row[i].type().)
> Realize that all three of these methods -- the two just mentioned, plus
> your home-grown alternative -- poke holes in the MySQL++ abstraction. You
> don't get to complain when the abstraction leaks on you.
> Specifically here, if MySQL++ ever does become DB independent, these
> mechanisms you're using will necessarily change, breaking the code you're
> writing that digs below MySQL++ to the MySQL C API level.
> MySQL++ Mailing List
> For list archives: http://lists.mysql.com/plusplus
> To unsubscribe: http://lists.mysql.com/plusplus