> > I was being half kidding, but only half. :-) >
given that that phrase could initiate another round of "web2py sucks" and that is actually a simple statement to say that that behaviour occurs only with standard sqlite, I was not kidding at all :P > > Maybe I should make a slice on how to fix this behaviour also for > > SQLite..... it's just a bit complicated because it requires to rebuild > the > > sqlite module with an updated library. > > Oh, that's unfortunate. I have to say, I having the SQLite as part of > Python (i.e. not rebuilding) is a huge win for getting new user's into > the early success that makes them (or at least me) happy to keep using > and expanding their Web2py usage. :-) > Yep, I don't know exactly the defaults, but I happen to see some major differences against various systems with standard python distribution. Having sqlite3 module included by default it's absolutely a win, but because of its nature of static linked module to a .so or a .dll, it's quite a hassle to update. Moreover, it's just for this kind of functionality for webapps that could be beneficial to update the module, so I can understand a little bit the "standardized" api and "different" actual sqlite linked version. For having the possibility to avoid this locking one must activate WAL (http://www.sqlite.org/draft/wal.html) on the db. Unfortunately WAL needs sqlite version > 3.7.0 SQLite version is different from the sqlite3 python module version. On ubuntu 10.04, for example, default python is 2.6.5 >>> import sqlite3 >>> sqlite3.version '2.4.1' >>> sqlite3.sqlite_version '3.6.22' While on 12.04, default python is 2.7.3 >>> import sqlite3 >>> sqlite3.version '2.6.0' >>> sqlite3.sqlite_version '3.7.9' I don't know in other systems, but for windows builds it seems that replacing the dll shipped with python is sufficient. For linux (and maybe mac), one must build the sources separately, but with build extensions and pip that all boils down to (at the time of writing): sudo pip install http://pysqlite.googlecode.com/files/pysqlite-2.6.3.tar.gz --global-option build_static and use pysqlite2 instead of sqlite3 (web2py does this by default - tries to import pysqlite2, if not found falls back to standard sqlite3 - so no additional step required). As you can see, it's quite not a standard, and given that there are around installations of python 2.4 and that there's no "universal way" to get a simple "fix"..... could be a pain in the ass. Anyway, as Anthony suggested, writing something and apply "the theory" to that code can't replace a sane "test live functionality": every app has its kinds of loads, and percentages of writes/reads are absolutely not a standard.
