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.
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. 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.
-
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
Parameters: - sql_statement (str) – SQL statement string
- args (list) – SQL query parameters
Return type: list