Database Independence [merge]

[Stephen <trac@…>]

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 :)

[rocky]

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

[mcarpenter@…]

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

[anonymous]

==  ==

[cboos@…]

See also the DatabaseBackend design discussion.

[Brad Anderson <brad@…>]

A more recent PostgreSQL effort is ​here.

[cmlenz]

Sigh.

[cmlenz]

Thank you very much.

[cmlenz]

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

[mrowe]

sigh

[asir <toliuch@…>]

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.

[asir <toliuch@…>]

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

[cboos]

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.

[cboos]

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)

[cboos]

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

[clee@…]

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

[cmlenz]

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…

[anonymous]

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

[daejuan@…]

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.

[daejuan@…]

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?

[anonymous]

​http://trac.dsource.org/projects/test/wiki/PostgresqlPatch

[anonymous]

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

[gbc@…]

Well,

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…

[mgood]

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.

[trac@…]

patch against r2625 to enable experimentalMySQL support

[trac@…]

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!

[markus]

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

[trac@…]

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