[Trac] Re: PostgreSQL Conversion

[Justus Pendleton]

On 2005-01-14, Brad Anderson <brad at dsource.org> wrote:
> Then we could reserve returnvals[1] for SCCM.  Or just do the getopt() 
> refactoring like you suggest.

I think I like getopt better because we don't know what other command
line options we might want to extent initenv to have in the future.
Maybe a --authmethod=?  Or --enable-plugin=?  It might also make it
easier to handle SCCMs that take lots of options, say for remote,
password-locked repositories.

> The problem with this, then, is that there is a central place for SQL
> statements, and a bunch of disparate plugins.  What if my "different"
> ticket plugin doesn't use the same queries as the "basic" ticket
> plugin?

I haven't looked at the plugin module work and I suppose I should.  What
I was thinking was to try to separate the presentation phase from the
data retrieval phase as much as possible.  Rather than having the SQL
statements in trac itself, it would just call self.get_ticket (n).
During the plugin registration phase the we'd need some kind of
arbitration to decide, as you point out, which plugin's get_ticket will
actually be called.  But as far as trac is concerned it doesn't matter
whether a SQL select happens in get_ticket, or maybe a cache lookup, or
berkeley db get, or a filesystem access (for when someone writes fsfs,
of course :).

> I'd even go as far as saying that the whole data model would be better
> served with surrogate keys

I'll have to take your word for that.  Everything I know about databases
comes from an Oracle certification program I dropped out of after the
first unit...and that was four years ago :-)

> I feel like trac-admin needs a bunch of work as well.  I'd like to share 
> common functions with the WebAdmin module I worked up earlier.

When I was looking at trac-admin for the minimal changes I made I was
thinking it seemed like a lot of that functionality should be moved into
the trac package and trac-admin should just be a command line tool to
invoke the appropriate trac.admin.function.  It sounds like that's what
you want for WebAdmin, too.