Re: Debbugs: The Next Generation
On Tue, Aug 07, 2001 at 03:11:54PM -0500, Adam Heath wrote:
> Note, I already have a database schema. Look at
> master/~doogie/debbugs/import.pl.
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.
This is intended to work in concert with the flat file data, not replace it,
correct?
(It turns out you answered that question below)
> On Wed, 8 Aug 2001, Matt Zimmerman wrote:
> > I chose C++ because it's relatively easy to use C and C++ code from interpreted
> > languages, but not to share code written in, say, Perl, with other languages.
> > With the current debbugs, there seems to be a choice between using the Perl
> > stuff or parsing the files yourself. While munging the text files by hand
> > isn't that unappealing, futzing with the database by hand is, so I would prefer
> > to share that code.
>
> Those who work on debbugs want an easily maintainable system. C/C++ do not
> come to mind as being in that category.
Are you claiming that the current debbugs code is easily maintainable?
> The proper way to do this, is to have a low-level(read c/c++) library that
> does the absolute bare minimum to store the data in some kind of back end.
> Then, the logic can be implemented in whatever language is desired.
That is essentially what I have tried to do. The only logic in the library
directly relates to representation and storage (merging, etc.), except for the
command processor, which is a convenience class.
> Note, the above can be read as reimplementing a cross-platform, langauge
> agnostic, data querying language.
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.
> > > Personally, I'd be inclined towards changing the .log format to be
> > > something akin to batched-SMTP and stored in the filesystem (so that it
> > > can be "replayed" if the database crashes; and so that the way the bugs
> > > logs are displayed can be changed in future).
>
> My goal was to use mbox for .log. Get rid of .report. And only use a
> relational database for readonly queries, and not make it the authorative
> version of the data.
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.
--
- mdz
Reply to: