From e47b573b3eda9c93f56ecdb86b9c6c66fe4698f1 Mon Sep 17 00:00:00 2001 From: lakshyacis Date: Thu, 10 Oct 2019 12:56:39 +0530 Subject: [PATCH] helper_sql pylint fixes --- src/helper_sql.py | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/helper_sql.py b/src/helper_sql.py index 16d36637..e7f2a60e 100644 --- a/src/helper_sql.py +++ b/src/helper_sql.py @@ -2,9 +2,11 @@ SQL-related functions defined here are really pass the queries (or other SQL commands) to :class:`.threads.sqlThread` through `sqlSubmitQueue` queue and check or return the result got from `sqlReturnQueue`. + This is done that way because :mod:`sqlite3` is so thread-unsafe that they won't even let you call it from different threads using your own locks. SQLite objects can only be used from one thread. + .. note:: This actually only applies for certain deployments, and/or really old version of sqlite. I haven't actually seen it anywhere. Current versions do have support for threading and multiprocessing. @@ -92,13 +94,15 @@ def sqlExecute(sqlStatement, *args): sqlLock.release() return rowcount + def sqlStoredProcedure(procName): + """Schedule procName to be run""" sqlLock.acquire() sqlSubmitQueue.put(procName) sqlLock.release() -class SqlBulkExecute: +class SqlBulkExecute(object): """This is used when you have to execute the same statement in a cycle.""" def __enter__(self):