| Version 6 (modified by , 19 years ago) ( diff ) |
|---|
Database Backend
Currently, Trac uses SQLite as its database backend.
However, there has 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 PostgreSQL: source:/branches/rocky-dev/features/postgresql_support/ though this branch is not so active this days…
- 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. this is a problem in 0.7.1, 0.8, and 0.9, so ticket gets multiple versions marked on it), 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:
- 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: 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!" Ie. 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?
