I think this patch looks dubious.

1. It tries to solve a backend specific issue in the backend agnostic 
dbconnection module. Importing mysql specific stuff in dbconnection 
should be a big no-no
2. It erroneously considers any OperationalError exception as a need to 
reconnect, instead of doing this only if the code is 2006 (thus it is 
hiding errors).


A proper fix for this was included in the patch that was send recently to 
unify the database exceptions.

In short it boils down to add and extra test for the 2006 code in 
_executeRetry function in mysqlconnection.py

The line:
if e.args[0] == 2013: # SERVER_LOST error

should read

if e.args[0] in (2006, 2013): # SERVER_GONE or SERVER_LOST


On Thursday 03 August 2006 00:02, sophana wrote:
> I will try the patch below.
> Has anybody tried it?
> This feature seems to be a must-have, don't you think?
>
> gentoo sqlobject # diff -Nura dbconnection.py.orig dbconnection.py
> --- dbconnection.py.orig        2006-07-26 23:21:23.000000000 +0800
> +++ dbconnection.py     2006-07-27 00:12:44.000000000 +0800
> @@ -214,11 +214,27 @@
>          self._binaryType = type(self.module.Binary(''))
>
>      def _runWithConnection(self, meth, *args):
> +        try:
> +            import _mysql_exceptions
> +        except ImportError:
> +            MySQLdbExcept = ImportError
> +        else:
> +            MySQLdbExcept = _mysql_exceptions.OperationalError
> +
>          conn = self.getConnection()
>          try:
>              val = meth(conn, *args)
> -        finally:
> +        except MySQLdbExcept:
> +            #print "make reconnection"
>              self.releaseConnection(conn)
> +            conn = self.makeConnection()
> +            self._connectionNumbers[id(conn)] = self._connectionCount
> +            self._connectionCount += 1
> +            try:
> +                val = meth(conn, *args)
> +            finally:
> +                self.releaseConnection(conn)
> +        #finally:
>          return val
>
>      def getConnection(self):
>
> Jorge Vargas a écrit :
> > On 8/2/06, *sophana* <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > hi I don't have a direct answer to you but this is a known problem,
> > and is recurrent in Turbogears (we use SQLObject for the backend)
> > please follow the discussion here.
> >
> > http://trac.turbogears.org/turbogears/ticket/781
> > http://trac.turbogears.org/turbogears/ticket/872
> > <http://trac.turbogears.org/turbogears/ticket/872>
> >
> > if you browser the TG mailing you will find a couple of workarounds
>
> -----------------------------------------------------------------------
>-- Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys -- and earn
> cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVD
>EV _______________________________________________
> sqlobject-discuss mailing list
> sqlobject-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

-- 
Dan

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Reply via email to