Re: Debbugs: The Next Generation
On Tue, Aug 07, 2001 at 04:08:33PM -0500, Adam Heath wrote:
> On Wed, 8 Aug 2001, Matt Zimmerman wrote:
>
> > The schema is not implicit in the script, but from what I can tell, it is
> > similar to what I came up with. You've done some additional processing of
> > email addresses, and you store package source/section/priority data in the
> > database as well.
>
> Look at schema.pm. Or, psql -U debbugs debbugs on master.
>
> What you mean to say here, is that all data is normalized.
Part of what I said there there was that you chose to duplicate data that is
already in another database. That is the opposite of normalization.
I do like the email part, though. I assume you've already done work on letting
users request notification on bugs.
> > I have not tried to implement a powerful query interface yet, only basic
> > package and bug-ID matching. It would be no small task to create a query
> > language powerful enough for a reasonable subset of conceivable BTS queries,
> > and then translate it into SQL. I've considered whether advanced reporting
> > applications shouldn't just talk to the database directly, exposing some
> > internal details in exchange for fast, flexible queries.
>
> Please see http://doogie.org/~adam/bugs-query.ws.
Looks very nice, and quick. What I was talking about, though, was a
programmatic interface for complex queries above the SQL layer. Does the
script do that behind the scenes, or does it talk to the database directly?
> > Did you plan to periodically do a full import, or simultaneously update both
> > stores? One of my goals was to speed up turnaround time, from receipt of the
> > initial report through updated output in the web interface, and that was the
> > rationale for making the database authoritative. It seems easier to
> > periodically translate database->flat files than to go the other way around.
>
> It takes 6.5-8 minutes to do a full import on master(it recently got an
> upgrade). The perl process uses 50 some megs of ram.
>
> 77182 bugs(it includes archived bugs). Only .status is in postgres, there is
> no reason for .log to be there.
I decided to store the message and history (.log) in the database for a few
reasons:
- Performance (it's easy to index and lookup the message which caused a change,
for example)
- Eliminate duplicate messages
- Fast and easy history queries (e.g. for bugreport.cgi)
> Also, look at /org/bugs.debian.org/spool/debbugs.trace. This file is updated
> whenever a bug changes state(which includes new bugs). However, bug
> archiving is currently not reflected in that file.
This is essentially what is contained in the 'history' table in my schema, but
I think my table shows only what changed, while debbugs.trace seems to list a
summary of the bug state. Also, I don't distinguish between archived and
active bugs.
You mentioned using mbox format for .log before; where does the change history
go in that case?
--
- mdz
Reply to: