Version 42 (modified by 12 years ago) ( diff ) | ,
---|
Database Backend
Initially, Trac only supported SQLite for its database backend (see PySqlite).
Postgresql support has been added as of Trac 0.9.
Mysql support will be added for Trac 0.10 (see this status report).
More generally, since milestone:0.10, Trac offers an easily extensible layer for Database support (see trac.db.api).
The existing backends have been refactored and integrated in this layer. There's currently bundled support for:
- SQLite, using PySqlite
- PostgreSQL, using the
psycopg2 bindings.
Note that psycopg1 is not supported anymore and that pyPgSQL also present issues for some users, see #5096).
Finally, see #126 for historical notes. - MySQL, using MySqlDb (see #986 for historical notes)
There's some work in progress for the following:
Backend Specific Installation Instructions
SQLite
Should be installed out-of-the-box, provided you have installed the PySqlite bindings.
Known issues: see pysqlite-related tickets
Postgresql
- Have a working copy of Postgresql
- Get the proper database driver for Python (see above)
- Create a database for your Trac environment
% createdb dbname
- Run trac-admin to create a new Trac environment. When prompted for a Database connection string, use:
postgres://user:pass@localhost:5432/dbname?schema=schemaname
Notice that the port number might be different in your Postgresql installation, e.g. 5433 (see postgresql.conf).
Alternatively on UNIX, if the database is a local one, you can use UNIX sockets instead of TCP/IP:
postgres://user:pass@/dbname?host=/path/to/unix/socket/dir&schema=schemaname
If you're using user trac without a password to connect through unix sockets to database trac and have only one project (hence no need for different schemas), your connections string would be postgres://trac:@/trac
- Note: '?host=…' is optional. Check your postgresql.conf' unix_socket_directory option if you have connection problems.
See #4546 for more details.
See also #2441, which discusses the process of migration from SQLite to Postgresql.
For a postgresql recipe tested on CentOS4 (Red Hat -EL4) see PostgresqlRecipe.
Note: Since Trac 0.10 the psycopg1 postgresql driver is no longer supported due to lack of unicode support.
Known issues: see postgres-related tickets
MySQL
It is somewhat supported by Trac since 0.10, but there are some limitations, documented in more details in the MySqlDb page. Use this only if you don't have other choice, and be warned that there can be many issues, in particular related to the unicode support and the repository cache support. Some users are nevertheless using MySQL successfully, so it can work for you, provided you carefully read and follow the instructions given in the MySqlDb page.
- Run trac-admin to create a new Trac environment. When prompted for a database connection string, use:
mysql://dbuser:dbpass@host:port/dbname
- or when you need more options:
mysql://dbuser[:dbpass]@host[:port]/dbname[?param1=value¶m2=value]
The following parameters are supported since Trac 1.0:
compress
: Enable compression (0 or 1)init_command
: Command to run once the connection is creatednamed_pipe
: Use a named pipe to connect on Windows (0 or 1)read_default_file
: Read default client values from the given file (also used for SSL configuration)read_default_group
: Configuration group to use from the default fileunix_socket
: Use a Unix socket at the given path to connect
Known issues: see mysql-related tickets
Users have reported success in Conversion from SQLite.
Alternative Ideas for Database Independence
Object-Relational Mapper
An ORM could be used to provide a unified object interface to different RDBMS:
- some people have been talking about using SQLObject to accomplish this goal of database independence.
- Modeling Another, more advanced (and more complex) OR-Mapper.
- SQLAlchemy seems to be also quite advanced
Comparisons between both and more info on Python ORMs:
- http://euc.cx/toulouse/archives/2003/04/21/evaluating_objectrelational_migration.html
- http://google.com/search?q=SQLObject+modeling
Store Tickets and Wiki pages directly in the Subversion repository
A compelling idea with many advantages. A page advocating this plan is TighterSubversionIntegration. There has also been a discussion on the Trac mailing list. All arguments from this discussion are summarized on the page WhySQLite.
Other Alternatives
- http://wiki.w4py.org/databaseintegration.html
- http://adodb.sourceforge.net - the fast ADODB db abstraction layer (version available for python)