List:MySQL++« Previous MessageNext Message »
From:Kevin Regan Date:June 14 2009 1:58am
Subject:Issue with ReconnectOption
View as plain text  
The MYSQL_OPT_RECONNECT (see below) has a problem before MySQL v5.1.6.  The option is
reset by mysql_real_connect.  Therefore, it must be set after the connection is
established.  However, MySQL++ has the following code when setting this option:

Option::Error
ReconnectOption::set(DBDriver* dbd)
{
#if MYSQL_VERSION_ID >= 50013
        return dbd->connected() ? Option::err_connected :
                        dbd->set_option(MYSQL_OPT_RECONNECT, &arg_) ?
                                Option::err_NONE : Option::err_api_reject;
#else
        return Option::err_api_limit;
#endif

It seems that the dbd->connected() check should only be performed for versions of MySQL
greater than 5.1.6.  I was able to do with with previous versions of MySQL++ (2.x).  Was
this just an oversight, or has something changed to make this an issue? 

--Kevin


MySQL reference:

MYSQL_OPT_RECONNECT (argument type: my_bool *)
Enable or disable automatic reconnection to the server if the connection is found to have
been lost. Reconnect is off by default; this option provides a way to set reconnection
behavior explicitly.
Note: mysql_real_connect() incorrectly reset the MYSQL_OPT_RECONNECT option to its default
value before MySQL 5.1.6. Therefore, prior to that version, if you want reconnect to be
enabled for each connection, you must call mysql_options() with the MYSQL_OPT_RECONNECT
option after each call to mysql_real_connect(). This is not necessary as of 5.1.6: Call
mysql_options() only before mysql_real_connect() as usual.

________________________________________
From: Kevin Regan [k.regan@stripped]
Sent: Saturday, June 13, 2009 6:27 PM
To: Jonathan Wakely
Cc: plusplus@stripped
Subject: RE: Why dynamic allocation for Option objects?

The change below seems to fix this.  I believe that the type_info object returned is a
singleton that outlives the object, but I'm not 100% sure of that.  Can some C++ expert
confirm this?

==== //depot/project/georgetown/ports/mysql++/build/lib/connection.cpp#1 -
/home/regan/dev/kregan-em-georgetown-ws1/ports/mysql++/build/lib/connection.cpp ====
@@ -314,13 +314,14 @@
 bool
 Connection::set_option(Option* o)
 {
+       const std::type_info& typeInfo = typeid(*o);
        error_message_ = driver_->set_option(o);
        if (error_message_.empty()) {
                return true;
        }
        else {
                if (throw_exceptions()) {
-                       throw BadOption(error_message_, typeid(*o));
+                       throw BadOption(error_message_, typeInfo);
                }
                return false;
        }



--Kevin
________________________________________
From: jonathan.wakely@stripped [jonathan.wakely@stripped] On Behalf Of Jonathan Wakely
[mysql@stripped]
Sent: Saturday, June 13, 2009 3:29 AM
To: Kevin Regan
Cc: plusplus@stripped
Subject: Re: Why dynamic allocation for Option objects?

2009/6/12 Kevin Regan:
> I was taking another look at this issue (please see the code below to following along
> with my issue).  If the DBDriver::set_option returns non-empty error string, wouldn't it
> have deleted the objected contained in o that Connection::set_option will call typeid(*o)
> on?

Yes, that's a bug.
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:    http://lists.mysql.com/plusplus?unsub=1
Thread
Issue with ReconnectOptionKevin Regan14 Jun
  • RE: Issue with ReconnectOptionKevin Regan14 Jun
  • Re: Issue with ReconnectOptionWarren Young16 Jun
    • RE: Issue with ReconnectOptionKevin Regan16 Jun
      • RE: Issue with ReconnectOptionKevin Regan23 Jun
      • Re: Issue with ReconnectOptionWarren Young25 Jun
        • RE: Issue with ReconnectOptionKevin Regan25 Jun
          • Re: Issue with ReconnectOptionWarren Young26 Jun