Edgewall Software

Opened 15 years ago

Closed 14 years ago

Last modified 13 years ago

#126 closed enhancement (fixed)

Database Independence [merge]

Reported by: Stephen <trac@…> Owned by: anonymous
Priority: high Milestone: 0.9
Component: general Version: devel
Severity: normal Keywords:
Cc: Branch:
Release Notes:
API Changes:


Specifically I would love to run trac against PostgreSQL, but if its architecture could be designed such that any DB-API compliant database can be plugged into it, that'd be great.

My reasons are this desire is interoperability. For example, I plan on coding up a subversion hook so that if someone writes 'closes #4' into the commit message, it'll close the issue. Also, the ability to generate dynamic reports in say, Excel, by connecting to the database via ODBC is desired by The Powers That Be.

This may or may not be possible w/ SQLite, but I'm familiar and confidant about PostgreSQL, so :)

Attachments (1)

trac_mysql_r2625.patch (10.4 KB ) - added by trac@… 13 years ago.
patch against r2625 to enable experimentalMySQL support

Download all attachments as: .zip

Change History (36)

comment:1 by rocky, 15 years ago

Owner: changed from Jonas Borgström to rocky
Status: newassigned
Summary: Database IndependanceDatabase Independance [merge]

I've provided a diff that removes all sqlite'isms and seems to enable Trac to run PostgreSQL.

comment:2 by Jonas Borgström, 15 years ago

Milestone: 0.8

comment:3 by daniel, 15 years ago

Milestone: 0.81.0

comment:4 by mcarpenter@…, 14 years ago

rocky you say you have a patch that would enable this. Could you attach it to this ticket?

comment:5 by anonymous, 14 years ago

Owner: changed from rocky to anonymous
Priority: normalhighest
Status: assignednew
==  ==

comment:6 by cboos@…, 14 years ago

See also the DatabaseBackend design discussion.

comment:7 by Brad Anderson <brad@…>, 14 years ago

Summary: Database Independance [merge]Database Independence [merge]

A more recent PostgreSQL effort is here.

comment:8 by anonymous, 14 years ago

Status: newassigned

comment:9 by anonymous, 14 years ago

Resolution: fixed
Status: assignedclosed

comment:10 by Christopher Lenz, 14 years ago

Resolution: fixed
Status: closedreopened


comment:11 by anonymous, 14 years ago

Component: generaltrac-admin
Milestone: 1.00.5
Priority: highestnormal
Resolution: worksforme
Severity: enhancementcritical
Status: reopenedclosed

comment:12 by Christopher Lenz, 14 years ago

Component: trac-admingeneral
Milestone: 0.50.9
Priority: normalhigh
Resolution: worksforme
Severity: criticalenhancement
Status: closedreopened

Thank you very much.

comment:13 by anonymous, 14 years ago

Component: generalproject
Resolution: fixed
Severity: enhancementmajor
Status: reopenedclosed

comment:14 by Christopher Lenz, 14 years ago

Component: projectgeneral
Resolution: fixed
Severity: majorenhancement
Status: closedreopened

Okay, you've had your fun. Stop this.

comment:15 by anonymous, 14 years ago

Resolution: fixed
Status: reopenedclosed

comment:16 by anonymous, 14 years ago

Resolution: fixed
Status: closedreopened

comment:17 by Mark Rowe, 14 years ago


comment:18 by asir <toliuch@…>, 14 years ago

To change the database backend to any standalone database server would give trac more concurrent transaction ability, since the source code repository backend(svn) can handle very large scale project(s). So, I think this ticket is very important for trac to be applied in the real world.

comment:19 by asir <toliuch@…>, 14 years ago

Severity: enhancementcritical

Trac would not be practical unless it works with a standalone database backend.

comment:20 by Christian Boos, 14 years ago

Severity: criticalenhancement

For you, perhaps. But for the vast majority of Trac users, SQLite is fine for the job: it's robust and fast, and a no-brainer to install, have you tried it? I would be curious to know with what kind of load it starts to moan… For example, I tried it with a copy of the Subversion repository (> 12000 commits, admittedly a big repository) without any problem.

I'm not saying anything against having the choice of DatabaseBackend. I only think it's not fair to dismiss Trac's rightful IMHO choice of SQLite as its first and default DB backend.

comment:21 by anonymous, 14 years ago

Resolution: wontfix
Status: reopenedclosed

comment:22 by Christian Boos, 14 years ago

Looking at the history of anonymous interventions on this ticket, I guess we have a TicketButcher at work here, who is practising DisagreeByDeleting

(btw, let's drop a quick InterWiki test here: Wiki:DisagreeByDeleting)

comment:23 by Christian Boos, 14 years ago

Resolution: wontfix
Status: closedreopened

… and then, getting distracted by the InterWiki idea, I forgot to reopen that ticket…

comment:24 by clee@…, 14 years ago

Doesn't trac provide a way to lock down status changes (resolve, close, reassign) to logged-in users via some sort of ACL?

comment:25 by Christopher Lenz, 14 years ago

Resolution: fixed
Status: reopenedclosed

Brad Andersons patch has finally been merged into trunk in [1671], [1672] and [1673]. Thus Trac now provides working PostgreSQL support! There are still a couple of hiccups, particularly environment upgrade and hotcopy, but I'm not sure what to do about those at this point…

comment:26 by anonymous, 14 years ago

Seems as though if PostgreSQL is implemented through a PyDB API module than MySQL support should also be trivial, right?

comment:27 by daejuan@…, 14 years ago

Not really, MySQL is the oddball when it comes to database servers. MySQL's nonstandard behavior and odd quirks will hurt you when programming abstraction layers.

comment:28 by daejuan@…, 14 years ago

I also forgot to mention, I believe, as someone suggested DatabaseBackend , ADOdb is something to look into. For the simple fact that the current 9.0 will use a library that hasn't been updated in 2 years PostgresqlPatch

comment:30 by anonymous, 14 years ago

Can't someone write a ConnectionWrapper that works with pysqlite2 ?

comment:31 by gbc@…, 13 years ago

Milestone: 0.91.0


the independence from a database as backend (or even a filesystem-based/Subversion based backend) would be agreat enhancement inho. Remember that many admins would love to see Trac and subversion running in THEIR enviromnent (guidlines from above…) w/o opening other ports/installing custom databases and so on. Why isn't there a plan for general abstraction layer from all that prequisites? It is really hard for me as unexperienced admin to get Trac and Subversion running in my Environment (IIS 5.1/MS SQL). I have no clue how to get everything running…

comment:32 by Matthew Good, 13 years ago

Milestone: 1.00.9

Please don't target closed tickets to future milestones.

If there are concrete suggestions for some of the topics mentioned above please file them as separate ticket, but if you just need support with the installation use the MailingList or IrcChannel to ask for help.

by trac@…, 13 years ago

Attachment: trac_mysql_r2625.patch added

patch against r2625 to enable experimentalMySQL support

comment:33 by trac@…, 13 years ago

I've added a patch for enabling MySQL support. At the moment it only supports connection strings in the format of: mysql://user:password@host:port/database mysql://user:password@host/database

I did have to make one database schema change because MySQL doesn't like to AUTO_INCREMENT a TEXT column, so I changed it to INT.

Beware: I still haven't tested to see if it breaks SQLite and PostgreSQL support!

comment:34 by markus, 13 years ago

Very nice! However, could you open a new ticket as this one is already marked as fixed and about adding PostgreSQL support?

comment:35 by trac@…, 13 years ago

Should I just reopen #986, which was marked duplicate of this, but does mention MySQL?

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain anonymous.
The resolution will be deleted.
to The owner will be changed from anonymous to the specified user.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.