I am on vacation (really) so I probably will not respond to any
reply to my below comments until July 10th.
Jeff, just to make sure I understand what is being said I'd like to
repeat what you are saying. In short the data upload from the
mtt client and the php script is done one test case at a time.
However, the bulk of a test run (a group of test cases) is written
as one table at some single point in time (when the run is done).
Is there no way for us to add rows to an existing table using perfbase?
Jeff Squyres (jsquyres) wrote:
>Andrew and I got on the phone to talk about the database stuff that
>we've been discussing on the mailing list. There were several
>miscommunications, but I think we understand each other now. Here's the
>- mtt does currently submit one test result at a time (e.g., the result
>of a single intel test). It certainly can be adjusted to submit them
>all at once, but right now it submits them individually.
>- a perfbase "run" is actually a unique *table* in the database that
>holds the variant data (not a *row* in an existing table, as I thought).
>Hence, submitting 400+ "runs" for a single invocation of the intel test
>suite would be so inefficient that we need to consider something better
>(especially since we'll be invoking the intel test suite potentially
>many times a night at each testing site -- so it's not just that we'll
>be creating boatloads of tables; we'll be creating N time boatloads of
>So for the moment, we do need to submit all the intel tests as a single
>"run", meaning that we have to submit them to the database all at once
>(how we upload them to the server is a different issue). This
>unfortunately means no partial results.
>For the immediate need, I think that this is ok because we're focusing
>on nightly tests where partial results aren't as important. But this is
>definitely something that we should ponder further as MTT becomes more
>pervasive (e.g., during a release cycle when we might be running MTT
>multiple times a day). It is probably even worth talking to the
>perfbase author about this issue [...starting to compose a mail to the
>perfbase mailing list...].