[Trac] Re: PostgreSQL Conversion

[Justus Pendleton]

On 2005-01-03, Brad Anderson <brad at dsource.org> wrote:
> This weekend, I tinkered with a patch to allow Trac to work with a PostgreSQL 
> database instead of SQLite.  It is just the beginning of what is required, 
> but I got most modules to at least come up and render data.

Brad,

I skimmed over your patch and had a few comments:

* For command line initenv usage I notice you've just added some more
  positional parameters, which is what I also did for new version control
  backends.  I think that someone eventually needs to rework initenv so
  that it uses normal getopt stuff to make these kinds of things easier to
  handle: e.g. what if someone wants darcs and postgres?  I'm not saying
  this necessarily belongs in your postgres patch, it was just something I
  noticed.

* What happens if the user types something other than pgsql for the
  database system?  I might be wrong but it looks as if any string that
  isn't "pgsql" is treated as sqlite.  I guess this is more along the lines
  of the pluggable modules but it would be cool if database support were a
  pluggable module.  You could query the installed modules to get a list of
  valid strings for database system.  The individual modules could even be
  smart enough not to register themselves if, for instance, you don't have
  pysqlite installed.

* In your motivations for this you mentioned performance.  trac doesn't
  use any indexes does it?  If not, we might want to add that for both
  sqlite and other db backends.

* In my darcs patch I've changed the revision id in the schema to be text
  rather than an int.  If we changed it to be text even for SVN would that
  help clean up any of those casts and hacks you have?  Or does it make
  things worse?

* It looks like you removed the exception trac raises when the web server
  doesn't have read/write access to the db directory.  Does sqlite just
  raise an exception under those circumstances?