PySqlite is a Python binding for the SQLite light-weight database engine, which is Trac's default DatabaseBackend.
If you're using Python 2.5 and up, you already have a working version of pysqlite 2, bundled as sqlite3
. You can stop here ;-)
If you are using an older version of Python or you'd like to benefit from the latest and greatest version of pysqlite, grab Windows installer or the source .tar.gz from the official Downloads.
If you need to build from this .tar.gz, simply do after unpacking:
python setup.py build_static install
This will fetch the latest SQLite version and bundle it within the extension.
OperationalError: unsupported file format
DatabaseError: file is encrypted or is not a database
OperationalError: SQL logic error or missing database
OperationalError: unable to open database file
OperationalError: database is locked
ProgrammingError: library routine called out of sequence
Warning: You can only execute one statement at a time.
DatabaseError: database is full
NameError: global name 'sqlite' is not defined
_sqlite.so: Undefined symbol "PyGILState_Ensure"
Trac supports SQLite 3.x, like SQLite 3.3.8, 3.5.6, etc. The latest tested as of this writing (3.6.12) works fine.
Pay attention to database format changes when upgrading the SQLite library.See below how to upgrade your database, if needed (SQLite v2.x is no longer supported in 0.12.x, use it at your own risks with earlier versions of Trac).The recent WAL mode introduced with sqlite 3.7.0 also works great with Trac.
The latest stable version of SQLite can be obtained on theSQLite download page.
But you don't need to download it by yourself, if you install the pysqlite bindings from a package, it will usually come with the SQLite code bundled.
If you build the pysqlite bindings by yourself, you alsohave the possibility to use the build_static
mode, whichwill download the latest "amalgamation" code of SQLite andbuild it together with the extension code.
If you really insist in being in full control…
Note: If you want to use Trac in a multi-threaded setupby using either TracModPython or TracStandalone, be sure to build athread-safe version of SQLite, by using the --enable-threadsafe
configuration switch.
If you use a non thread-safe library, which is unfortunately what youget by default on non-windows platforms, you face the risk to get persistent database locks (see #2170).
The latest stable version available at pysqlite.googlecode.com as of this writing is 2.5.6, and it works fine with Trac.
Detailed information about older releases:
sqlite3
package. Trac tries to use it if the pysqlite2
package is installed).mod_cache
(see Pysqlite:#174).Note that bug reports involving the obsolete pysqlite 1.0.x (for SQLite v2)will simply not be considered. Starting with 0.11.6, there will be an explicitdeprecation warning and in 0.12, support for that version will be removed.
The recommended way to build the SQLite bindings is to do a static_build
,which will download the latest sqlite3 amalgamation file, build and link it insidethe pysqlite module:
$ tar xvfz <version>.tar.gz $ cd <version> $ python setup.py build_static install
Note: Users of Mac OS X please take care; the Apple-supplied SQLite contains additional code to support file locking on network filesystems like AFP or SMB. This is not presently (3.3.6) in the mainline sources, so if you build your own SQLite from source it will not function correctly on such filesystems - typically it gives the error "database is locked
". A patch is available for version 3.3.6, based on Apple's code, otherwise you're probably best off using the Apple supplied version (presently 3.1.3).
It is not advised anymore to use SQLite 2.x. Support for this version and the corresponding PySqlite 1.0.x bindings will be dropped in Trac version 0.12.If you happen to use that version, you will need to upgrade.
The following information is copied from http://dev.ctor.org/pkcs1/wiki/TracUpgrade
The database formats used by SQLite 2.x and sqlite 3.x are incompatible. If you upgrade your SQLite version (this can also happen implicitly if you upgrade from PySQLite 1.0.x to 1.1.x or 2.x), then you must convert your database.
To do this, install both SQLite 2.8 and SQLite 3.x (they have different filenames so can coexist in the same directory). Then use the following commands (Windows):
$ mv trac.db trac2.db $ sqlite trac2.db .dump | sqlite3 trac.db
Then when you're happy with the conversion and tested everything you can delete the trac2.db file.
It's almost the same as above. The following shows you how to upgrade from 3.2.8 to 3.3.4:
$ mv trac.db trac-old.db $ LD_LIBRARY_PATH=/opt/sqlite-3.2.8/lib /opt/sqlite-3.2.8/bin/sqlite3 trac-old.db .dump | LD_LIBRARY_PATH=/opt/sqlite-3.3.4/lib /opt/sqlite-3.3.4/bin/sqlite3 trac.db
From time to time, there are reports about problems related toPysqlite and/or SQLite. This section willl guide you throughunderstanding and fixing those issues, should those problems also happen to you.
Troubleshooting is greatly helped by knowing exactly what versions are used for sqlite
inside your Python interpreter. Especially on *nix systems, a number of different versions might exist - and the actual versions linked and used might not be what you think.
To test the version of PySqlite what your Python installation uses and the version of SQLite linked, try this inside an interpreter:
>>> import sqlite>>> sqlite.version'1.0.1'>>> sqlite._sqlite.sqlite_version()'2.8.16'
To ensure that this is the exact version Trac uses - you may try this:
>>> import trac.db.sqlite_backend as sql>>> sql.sqlite_version(3, 7, 5)>>> sql.have_pysqlite2>>> sql.sqlite.version'2.6.0'
PySqlite is version 2 (2.6.0), compiled and linked to use version SQLite 3.7.5.
Another way to test the bindings with PySqlite 2 is to use:
>>> from pysqlite2 import dbapi2 as sqlite
This test should not fail.
To install SQLite, your system may require the development headers. Without these you will get various GCC related errors when attempting to build:
$ apt-get install libsqlite3-dev
Sometimes vacuum helps to fix inconsistencies in the db. See also pragma, command line, vacuum.
$ sqlite3 trac-parent/mytracinstance/db/trac.dbsqlite> PRAGMA integrity_check;... some errors ...sqlite> VACUUM;sqlite> PRAGMA integrity_check;ok
OperationalError: unsupported file format
This probably is symptomatic of a mismatch between the SQLite library and the SQLite database format.
See Trac-ML:7540
And this might be caused by a different version of PHP's pdo_sqlite module when you use Trac in mod_python mode. Check your pdo_sqlite module's version, or if OK, you may simply disable it (see /etc/php.d/pdo_sqlite.ini). (Note that sqlite 3.3.x and 3.2.x does not have compatibility.)
DatabaseError: file is encrypted or is not a database
There are typically three situations in which this somewhat cryptic error message can be seen:
OperationalError: SQL logic error or missing database
This can indicate that the database was corrupted.
A procedure similar to upgrading can be used in order to recoversuch a database:
sqlite3 corrupted.db .dump | sqlite3 recovered.db
(see #2598, for example)
This can also be the symptom of errors due to constraint violations
And this might correspond to an open bug. See #2902 and #2570.
OperationalError: unable to open database file
Besides the obvious reason of missing read permissions on the file, it can also happen when the server process has already opened too many files and is unable to open new ones due to O/S limitations. See #8551 for a detailed explanation. You can tell immediately between the two causes depending on the occurrence of the error: if the error is systematic, it's a permission problem, if it's only transient and happening under load, then it's likely the second.
OperationalError: database is locked
There are numerous reasons why you can get this.
First, if this only happens occasionally and if the Trac serveris still reachable after a second attempt, then it's not reallya problem. This simply can happen and indicates that someother user was writing to the database at the same time yourrequest triggerd an attempted to write.There are probably a few things that could be enhanced in thefuture to handle this situation, like automatic retry, see #3446.
Also, is this error is somehow inevitable with SQLite, we should make the error message a bit more "user friendly" (#3503).
The lock error is also much more frequent if SQLite is used in a multi-threaded environment (like TracStandalone or TracModPython) but the library was not compiled to be thread-safe. See above, building from source, and #2170.
The real problem with this occurs when all requests to Tracend up with this error. This indicates a permanent lock situation,which is not normal. Here are the known possible reasons for this:
See also: SQLite:DatabaseIsLocked.
ProgrammingError: library routine called out of sequence
This happens on MacOS X, and is still an open issue (see #2969)
See also: SQLite:LibraryRoutineCalledOutOfSequence.
Warning: You can only execute one statement at a time.
This is typically an error which happens when the pysqlite package you're using is loading at runtime a sqlite3.so
library which hasa different version than the one against which pysqlite was built(e.g. see #2993).
DatabaseError: database is full
Besides the obvious reason (no space left on the partition wherethe trac db resides), you probably ran out of space in either/tmp
or /var/tmp
, where SQLite apparently needs to write too.See #2356, #ps20.
NameError: global name 'sqlite' is not defined
This error usually comes from an invalid PySqlite installation:
The Python interpreter is not able to import the sqlite module.
...File ".../python2.3/site-packages/trac/db.py", line 321, in init_db cnx = sqlite.connect(path, timeout=int(params.get('timeout', 10000)))NameError: global name 'sqlite' is not defined...
python>>> import sqlite
<python_lib_dir>/site-packages
. If you've installed the module in another directory, make sure the sys.path
variable is set up with this directory (more on this in TracCgi, TracModPython, TracFastCgi).A common mistake is to install PySqlite for one Python interpreter, and run the server with another Python interpreter: both interpreters do not use the same paths to search for modules.
Another possible mistake is the pysqlite2 installer forgot to make "_sqlite.so" dll unreadable by anyone other than root. Fix by chmod 775 _sqlite.so inside $PYTHON_PATH/site-packages/pysqlite2/.
Also make sure you ld.so.cache (ldconfig —print-cache (if using debian)) finds the correct path for installed libraries that Trac depends on. If can't modify, set set your LD_LIBRARY_PATH to point where sqlite dlls are installed.
_sqlite.so: Undefined symbol "PyGILState_Ensure"
If after the import test you encounter this message it most likely means that your Python was not compiled with threads support. On FreeBSD this is easily verified by doing a grep -i threads /var/db/ports/python24/options
. If it comes back with a WITHOUT_THREADS=true
you need to configure Python to be compiled with threads by executing make config
in the appropriate Python ports directory and subsequently recompile and replace Python.
InterfaceError: Cursor needed to be reset because of commit/rollback and can no longer be fetched from.
When upgrading trac databases from 0.11.x to 0.12, the trac-admin upgrade script will die with this error due to a bug in PySqlite versions 2.5.2-2.5.4. It is advised to use either a newer or older release to successfully upgrade. See ticket #9434 for full details.
Segmentation Fault
Some old Python 2.3 versions (like on SuSE 9.0) have a bugrelated to gc and weakrefs, which might be triggered by Trac.
(details)
Segmentation faults can also happen in multi-threaded servers using a SQLite library which has not been configured to be multi-thread safe (see above).
P.S. Note that despite of all of the above, for some (most?) users, SQLite/Pysqlite works flawlessly :)
联系客服