cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Boag/CAM/Lotus" <Scott_B...@lotus.com>
Subject Re: xBug
Date Fri, 21 Jan 2000 04:38:46 GMT

> 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.

> 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.

-scott




                                                                                         
                         
                    Donald Ball                                                          
                         
                    <balld@websli        To:     cocoon-dev@xml.apache.org            
                            
                    ngerZ.com>           cc:     (bcc: Scott Boag/CAM/Lotus)          
                            
                                         Subject:     Re: xBug                           
                         
                    01/20/00                                                             
                         
                    10:46 PM                                                             
                         
                    Please                                                               
                         
                    respond to                                                           
                         
                    cocoon-dev                                                           
                         
                                                                                         
                         
                                                                                         
                         




On Thu, 20 Jan 2000, Jerm wrote:

> Dear All,
>
> I have been in discussion with Stefano over the last couple of days,
about
> building a Bug Tracking system for Cocoon, in Cocoon.
>
> After going over various ways of handling this, we decided that the only
> technique that really makes any sense, is to store bugs in an SQL
Database.

I dunno, I take some issue with this. Yes, I wrote the current version of
the SQLProcessor (and am working on the taglib version), but I'm not
necessarily the SQL advocate. I think you should only mess around with
storing data in a SQL database instead of in an XML file if there are an
insane number of entities to be stored (more than a few hundred to a
thousand, depending on the complexity of the entities), or if your
commonly performed queries are complex and performance is really critical.
For most things, I'd much rather put the data into an XML file (or a set
of 'em) and use XSLT (and by extension, XPath) to extract and render the
bits that I'm interested in. Writing complex SQL queries, or even worse,
writing logic to write complex SQL queries, is much more painful IMHO.

Furthermore, it's much easier to add, uh, special case data fragments in
XML than it is in SQL. For instance, suppose you decided that each bug
report would be assigned to single designated fixer, but then you ran into
a bug that needed to have two designated fixers. In XML, you'd just add
another <fixer> to the <bug>, but in SQL you'd either have to add a series
of columns to the bug table (e.g. fixer2_name, fixer2_email) or you'd have
to move the fixer information to a foreign table and then put a reference
to the foreign table in the original bug table and then rewrite all of
your queries that reference fixer to do the lookup into the foreign table.
Ick.

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. Plus it'd give us some valuable experience working with largish
XML datasets. I wrote SQLProcessor to give myself a bridge to 'legacy'
data, and to access datasets that I simply couldn't work with as straight
XML (e.g. databases with thousands of articles with thousands of words).

Perhaps I am missing some compelling reason to choose SQL for this app
though? If so, I'd love to hear it.

- donald






Mime
View raw message