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:
http://lsd.student.utwente.nl/gump/gump_stats/index.html
and into projects:
http://lsd.student.utwente.nl/gump/ant/ant.html#Statistics
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.
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=3237
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.
http://www.betaversion.org/~stefano/linotype/news/46/
... 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.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
