>> By including PySQLite we'd somehow be blessing it as a better SQL >> solution than the other options. That means it will almost certainly >> be stretched beyond its limits and used in situations where it isn't >> appropriate (multiple writers, writers that hold the database for a >> long time, etc). That will reflect badly on both SQLite and Python.
Bob> I can't imagine how that rather contrived scenario could reflect Bob> badly on Python or SQLite.
You assume it was contrived, but it wasn't at all. We hit exactly these problems almost upon first use. We were in the process of copying a large amount of data from our corporate Sybase database. Because SQLite's lock granularity is the entire file, the SQLite database was unusable until the entire update process was complete, even though many tables were completely updated long before the update process finished. We also encountered a major performance problem almost immediately. It seems that using BETWEEN is much worse (order of magnitude worse) than two comparison clauses using
=, <, etc.
We are in the process of deciding which server-based SQL solution to move to.