Edgewall Software

Version 9 (modified by haui@…, 19 years ago) ( diff )

voted for "Tighter Subversion Integration"

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 advantages: see a more complete discussion in TighterSubversionIntegration

Pros

(some 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."
  • Trac currently mixes transient and non-transient data in a single database. By storing all valuable data (which cannot be reconstructed by resynching with the repository) in a version controlled data store would help separating both sorts of data and minimize the amount of data that needs to be backed up.

Cons

  • no SQL — There is no reason why Trac might not store "transient" data in a regular database. Such database would be required anyway, because some features of Trac need indexing for fast searching.
  • (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 — If this really is an issue, this could also easily be solved by using a different repository for storing issues and wiki pages.

There seem to be more cons :( - the Subissue project ​seems to be dead. There are especially no cons without remedy. There are more dead projects than alive ones — this is no reason for not implementing the feature that eveybody first thinks of after downloading Trac…

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.