= Database Backend = Currently, Trac uses [http://www.sqlite.org SQLite] as its database backend. However, there have been several requests that other databases should be supported as well (see #126). == Existing Proposals and Implementations == * There has been an attempt to provide support for [http://www.postgresql.org PostgreSQL]: source:/branches/rocky-dev/features/postgresql_support/ though this branch is not so active this days... * A more recent PostgreSQL effort is [http://trac.dsource.org/projects/test/wiki/PostgresqlPatch here]. * Data Model Change If SQLObject (see below) works well, this proposal may not be necessary, but I would like some feedback (brad at dsource dot org) on the following proposal: [http://trac.dsource.org/projects/test/wiki/TracTicketDataModelChanges TracTicketDataModelChanges] I like its elegance in handling custom fields, allowing multiple ticket attributes per ticket (i.e. the ability to indicate all the versions of the software that a bug is present in, rather than being limited to indicating a single version), and I imagine it results in reduced code overall for the app because of the use of metadata. == Object-Relational Mapper == provide a unified object interface to different RDBMS * SQLObject I think some people have been talking about using [http://sqlobject.org SQLObject] to accomplish this goal of database independence. * [http://modeling.sourceforge.net/ Modeling] Another, more advanced (and more complex) OR-Mapper. Comparisions between both and more info on Python ORMs: * http://toulouse.amber.org/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 [wiki:WhySQLite WhySQLite]. == Other Alternatives == http://wiki.w4py.org/databaseintegration.html http://adodb.sourceforge.net - the fast ADODB db abstraction layer (version available for python)