--On Saturday, February 5, 2005 10:51 PM -1000 "(Cedric) Qin ZHANG" <[EMAIL PROTECTED]> wrote:
I want to use the existing flat persistence scheme (much simpler), but I just don't know how. Can somebody help me?
Hi Cedric,
This is exactly like the situation with FileMetrics, where we want to be able to aggregate together a set of individual FileMetrics records in order to represent the size of a complete system. What we do in that case is include a "runtime" attribute that is used to identify that a set of FileMetric sensor data (each with distinct tstamp values) were generated from a single invocation of the tool (LOCC). You can follow the same approach to resolve your problem.
BTW, under this scheme, in order to count the number of builds in a given day, you just count up the number of distinct "runtime" values.
Now, this does require us to rethink the semantics of the Build SDT. We probably want to make "runtime" a required field, and we want to modify the specification to say that a single invocation of a Build tool can result in multiple Build sensor data being generated, each one describing a distinct result from the build. That seems like a nice improvement to the current specification.
One other thing. While we're hacking the Build SDT, could you please add a field that represents the top-level target(s) that were invoked? For example, it's interesting to know in the case of Hackystat whether the build failed (or succeeded) as a result of running:
ant quickStart
vs.
ant freshStart junitAll
It also turns out that knowing the top-level target passed to "make" (and the results) is very useful in Mike's HPC research.
Let us know if you see additional problems.
Cheers, Philip
