Edgewall Software

Version 8 (modified by anonymous, 19 years ago) ( diff )

added another DBMS abstraction library

Database Backend

Currently, Trac uses ​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

  • A more recent PostgreSQL effort is ​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: ​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 ​SQLObject to accomplish this goal of database independence.
  • ​Modeling Another, more advanced (and more complex) OR-Mapper.

Comparisions between both and more info on Python ORMs:

Store Tickets and Wiki pages directly in the Subversion repository

A compelling idea with many: see a more complete discussion in TighterSubversionIntegration

Pros

(taken from ​Subissue, a project that aims to implement such a solution)

  • "Issues are stored directly in your Subversion repository, next to your source — right where they belong!" i.e. you have access to your issues and project documentation (wiki) by just checking out your source.
  • no extra RDBMS required; Subversion already has its own database.
  • "logging, intelligent reporting, history, and access control straight out of the box: most everything required for issue tracking is already in place — right down to email notification."

Cons

  • no SQL
  • (from ​411) revision numbers of the repository would climb like crazy because every ticket added or edited would create a new changeset — but a different, dedicated, repository could be used instead the one being Trac'ed
  • (from ​411) trac currently does not modify the repository at all — changing it to do so might create other problems — which ones?

There seem to be more cons :( - the Subissue project ​seems to be dead.

See also ​<Trac> Why does Trac use SQLite for Wiki?

Other Alternatives

​http://wiki.w4py.org/databaseintegration.html

​http://adodb.sourceforge.net - the fast ADODB db abstraction layer (version available for python)

Note: See TracWiki for help on using the wiki.