[Trac] Re: PostgreSQL Conversion

[Brad Anderson]

Justus,

I got a mail from you, and am not having any luck replying to it.  Want to 
send another one with an alternate address?  I stripped out the '-dated-*' 
stuff, but it still didn't work.

BA


On Friday 14 January 2005 10:46 am, Justus Pendleton wrote:
> 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.
>
> _______________________________________________
> Trac mailing list
> Trac at lists.edgewall.com
> http://lists.edgewall.com/mailman/listinfo/trac