pybitmessage.helper_sql module

SQL-related functions defined here are really pass the queries (or other SQL commands) to threads.sqlThread through sqlSubmitQueue queue and check or return the result got from sqlReturnQueue.

This is done that way because 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.


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. I don’t see an urgent reason to refactor this, but it should be noted in the comment that the problem is mostly not valid. Sadly, last time I checked, there is no reliable way to check whether the library is or isn’t thread-safe.

sqlSubmitQueue = <Queue.Queue instance>[source]

the queue for SQL

sqlReturnQueue = <Queue.Queue instance>[source]

the queue for results

sql_lock = <thread.lock object>[source]

lock to prevent queueing a new request until the previous response is available

sql_available = False[source]

set to True by threads.sqlThread immediately upon start

sql_ready = <threading._Event object>[source]

set by threads.sqlThread when ready for processing (after initialization is done)

sqlQuery(sql_statement, *args)[source]

Query sqlite and return results

  • sql_statement (str) – SQL statement string
  • args (list) – SQL query parameters
Return type:


sqlExecuteChunked(sql_statement, idCount, *args)[source]

Execute chunked SQL statement to avoid argument limit

sqlExecute(sql_statement, *args)[source]

Execute SQL statement (optionally with arguments)


Execute SQL script statement


Schedule procName to be run

class SqlBulkExecute[source]

Bases: object

This is used when you have to execute the same statement in a cycle.

static execute(sql_statement, *args)

Used for statements that do not return results.