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
