On 27/11/2007, Oleg Broytmann <[EMAIL PROTECTED]> wrote: > On Tue, Nov 27, 2007 at 02:02:02PM +0100, Markus Gritsch wrote: > > How about applying the attached patch? > > --- mysqlconnection_orig.py 2007-09-27 02:18:28.000000000 +0200 > +++ mysqlconnection.py 2007-11-27 13:57:30.324125000 +0100 > @@ -110,10 +110,7 @@ > # For MySQLdb 1.2.1 and later, we go > # encoding->unicode->charset (in the mysql db) > if self.need_unicode and not isinstance(query, unicode): > - try: > - query = unicode(query, self.encoding) > - except UnicodeError: > - pass > + query = unicode(query, self.encoding) > return cursor.execute(query) > except MySQLdb.OperationalError, e: > if e.args[0] in (MySQLdb.constants.CR.SERVER_GONE_ERROR, > MySQLdb.constants.CR.SERVER_LOST): > > I remember people had been persuading me to add that try/except for years, > and now you are starting the reverse process! :)
I have been persuading you to add the "and not isinstance(query, unicode)" part of the if for month and since it was added, the MySQL backend gracefully accepts Unicode in queries ;) However, this silently swallowing of an UnicodeError was introduced from 0.9.1 -> 0.9.2 and I don't see what bug this solves. It just makes me feel uneasy. If there is really a case for which the conversion to unicode using self.encoding raises UnicodeError, then fixing it by swallowing this exception is definitely not the correct solution to the problem. Unless someone can come up with a short code example of a program which works only with the try/except being there and fails without it, I would rather like to see the try/except being removed. Markus ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ sqlobject-discuss mailing list sqlobject-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
