id,summary,reporter,owner,description,type,status,priority,component,severity,resolution,keywords,cc,release
7262,db.close() should not be used in trac 0.12,ejucovy,k0s,Don't close the db connection after each SQL command is executed.  In Trac 0.12 this causes subsequent db queries to have no connection_ causing !AttributeErrors.\r\n\r\nPatch:\r\n{{{\r\n#!diff\r\nIndex: tracsqlhelper/__init__.py\r\n===================================================================\r\n--- tracsqlhelper/__init__.py	(revision 8119)\r\n+++ tracsqlhelper/__init__.py	(working copy)\r\n@@ -29_10 +29_10 @@\r\n Exception:%s""" %(sql_ params_ e))\r\n             db.rollback()\r\n             raise\r\n-        try:\r\n-            db.close()\r\n-        except:\r\n-            pass\r\n+        #try:\r\n+        #    db.close()\r\n+        #except:\r\n+        #    pass\r\n         return self.return_values(**_data)\r\n}}}\r\n\r\nAFAICT this is a band-aid over a bigger issue.  SQLHelperScript does not distinguish between commands that write to the db and commands that only read from it -- all commands will commit and roll-back the database.  It also tries to manage its own database connections (get_db_cnx and the now-commented-out db.close()).  And in fact it seems like as of Trac 0.12 it should not be trying to manage its own transactions either_ or if it does it should be using the with_transaction decorator.  But my hunch is that none of this should be managed at the level of the individual SQL command \r\nobjects_ rather by their callers.\r\n\r\nRegardless this small change seems to fix the immediate issue_ [/ticket/7182#comment:4 comment:4:ticket:7182]-- though I don't know if it will cause additional problems.,defect,closed,normal,TracSqlHelperScript,normal,fixed,,,0.12