cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <>
Subject Re: xBug
Date Fri, 21 Jan 2000 19:15:34 GMT
On Thu, 20 Jan 2000, Scott Boag/CAM/Lotus wrote:

> > Naw, for the number of bugs per project I think we'll have (several dozen
> > to a hundred?) I can't see any reason to go through the trouble of
> messing
> > with SQL.
> Huh?  A bug database should store all bugs that ever occured.  I would say,
> over the course of a project spanning years, that will probably be in the
> thousands.

Sure, but you can move bugs from the 'active' bug file to the 'fixed' bug
file once they're patched and thus reduce the number of bugs you're
typically running queries against (and from the 'fixed' to the
'historical' file once they've lagged a couple of minor or a major release
behind the current version). But yes, I concur, you should store the bugs
practically forever.

But this is the cocoon project, remember? Even if we track all bugs over
the course of several years we're only talking about 5 or 6, right? :)

> > and use XSLT (and by extension, XPath) to extract and render the
> > bits that I'm interested in.
> With the right setup, you can extract and render via XSLT with an
> SQL/relational database.

Right, you could use SQLProcessor to get data from the SQL database as
XML. I just don't know that it's worth the extra trouble (having to deal
with SQL inflexibility, having to write the translation layer, and having
to manage it over time). I could be wrong, it may well be worth the extra
trouble, I just didn't see any reasoning behind the assertion that the
only way to do this was to put the data in SQL. I think web developers
have a tendency to cram everything into SQL databases without analyzing
whether or not it's truly desirable first.

- donald

View raw message