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....
Working on Step III:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=3772
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
