gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Gump Database
Date Sun, 29 Feb 2004 00:55:11 GMT
Adam R. B. Jack wrote:

> Just to start afresh on this topic:
> Right now Gump uses a Python DBM database (on platforms other than M$, where
> that currently isn't supported) to store a set of states/dates/counters,
> i.e. what is the current & last state, how 'long' in this state, when first
> built, how man successes, how many failures, etc. Basically, the stuff that
> goes into here:
> and into projects:
> Basically, I don't wish to use DBM for anything more than this, and I would
> like to start storing some historical/trend/change information.
> Clearly RDBMS as a likely candidate, stuff we all know and are generally
> comfortable with. We could generate a schema to hold the runtime data and
> (with help from Berin's pointers) it seems Python can query/update this.
> Since Gump has so much XML (in workspaces, profiles, modules, projects etc.)
> perhaps an XML store is a good candidate. I could see (for descriptors and
> such) having the ability to detect changes in XML (from last instance) could
> be useful. I could also see us wanting to query over the workspace XML and
> the results.
> I recently exercised XINDICE, and tried to step outside of my biases and see
> if an XML store was a good thing. I never got past thinking of it as random
> buckets-o-XML, and didn't find what I hoped to.
> That all said, I kinda like what Stefano wrote & worry a relational model
> could impede some of the more exciting and serendipitous results we'd like
> to see.
> ... although he's being a bit of a tease and not doing his thinking out load
> for us. ;-)
> I know Nick wants us to store the HTML output historically, so I wonder if
> storing the XML outputs the same way might not be so bad. [Not good for
> cross date queries, but...]
> In short, I don't know the right approach & am open to all ideas. Also, this
> smells like something we ought discuss/design here and on the wiki.
> regards,
> Adam
> P.S. I know folks think an XML result could be converted to graphical graphs
> for Forrest documentations, and since I am eager to work on generating a
> result.xml (am currently using xml.dom.minidom, my new buddy, to write that)
> I could easily generate other result XML files. So, specify/request away....

For this specific problem, I would go relational.

Your data is very structured, the schema not so complex, the queries 
don't need cross-dataset semantics and XML can be generated from a 
relational query very easily (forrest can do that too using the cocoon 
SQL modules)

Storing it with XML is, IMO, golden hammer.


View raw message