How do we deal with row # now that we don't have temporary tables? I
remember having to hack around this a bit to get it to work.
What I was initially thinking was that we would tag each row with
it's corresponding triplet [mpi_install_id, test_build_id,
test_run_id] then use the appropriate ID when executing the query.
All three for all three phases, test_run_id for test_run phase, etc.
The tag table fields would look something like:
tag_id, tag, mpi_install_id, test_build_id, test_run_id
So a single triplet can still be associated with multiple tags.
Something to ponder some more before next weeks meeting.
On Aug 27, 2007, at 11:45 AM, Ethan Mallove wrote:
> With regards to a Gmail-style interface for labeling, got a
> comment/concern on the SQL.
> IIRC, when cherry-picking was implemented (for performance
> reports), we attempted to compose a WHERE clause that would
> effect the cherry-pick. This led to some wild WHERE clauses.
> E.g., consider the following example:
> |# |A |B |C |D |
> |1 |1 |2 |3 |4 |
> |2 |5 |6 |7 |8 |
> |3 |9 |10 |11 |12 |
> |4 |28 |10 |11 |12 |
> |5 |29 |10 |11 |12 |
> If we want to cherry-pick lines 1, 2 and 3, then our WHERE
> clause will look like this:
> SELECT blah blah FROM blah,blah
> (A=1 AND B=2 AND C=3 AND D=4) OR
> (A=5 AND B=6 AND C=7 AND D=8) OR
> (A=9 AND B=10 AND C=11 AND D=12)
> We eventually chose do the filtering in PHP on row # since
> there does not seem to be a good way to filter by row # in
> SQL. The point being, a nasty WHERE clause *could* lead to a
> loooong tag operation.
> Given the above, a good starting point might be to restrict
> tagging to the following:
> 1. Allow tagging only on entire reports
> 2. Allow tagging only on a single row at a time
> My $0.02.
> On Fri, Aug/24/2007 03:07:54PM, Jeff Squyres wrote:
>> I volunteered to do this on the call today. Here's my thoughts on
>> 1. From the client, it would be nice to be able to specify a comma-
>> delimited list of tags at any phase. Tags would be inherited by
>> successive phases if not explicitly overridden. E.g., if you specify
>> a "foo" tag in an MPI get, it'll be used in all phases that use that
>> MPI get.
>> Tags can be specified in one of three forms:
>> +foo: means to *add* this tag to the existing/inherited set
>> -foo: means to *remove* this tag from the existing/inherited set
>> foo: if any tag does not have a +/- prefix, then the inherited set
>> is cleared, effectively making the current set of tags be only the
>> non-prefixed tags and +tags
>> For example:
>> [MPI Get: AAA]
>> # + and - have little meaning for MPI Get
>> tags = foo, bar, baz
>> [Test Get: BBB]
>> # + and - have little meaning for Test Get
>> tags = yar, fweezle, bozzle
>> [Test Build: CCC]
>> # Test build inherits tags from MPI Get and Test Get
>> tags = +fa-schizzle, -yar
>> # Resulting tag set: foo, bar, baz, fweezle, bozzle, fa-schizzle
>> [Test build: DDD]
>> # Override everything
>> tags = yowza, gurple
>> # Resulting tag set: yowza, gurple
>> 2. For the reporter, I think we only want authenticated users to be
>> able to create / manipulate tags. Authentication can be via SVN
>> username / password or the HTTPS submit username / password; I don't
>> have strong preferences.
>> Anyone can query on tags, of course.
>> 3. We should have easy "add these results to a tag" and "remove these
>> results from a tag" operations, similar to GMail/labels. I think the
>> rule should be that if you can show MPI details (i.e., not the
>> summary page), you can add/remove tags. Perhaps something as simple
>> as a text box with two buttons: Add tag, Remove tag.
>> 3a. Example: you drill down to a set of test runs. You type in "jeff
>> results" in the text box and click the "add tag" button. This adds
>> the tag "jeff results" to all the result rows that are checked (it is
>> not an error if the "jeff results" tag already exists on some/all of
>> the result rows).
>> 3b. Example: you drill down to a set of test runs. You type in "jeff
>> results" in the text box and click on the "remove tag" button. This
>> removes the tag "jeff results" from all the result rows that are
>> checked (it is not an error if the jeff results" tag is not on some/
>> all of the result rows).
>> 4. Per Gmail index label listing, it would be nice to see a list of
>> tags that exist on a given result row. It could be as simple as
>> adding another show/hide column for the tags on a given result row.
>> But it gets a little more complicated because one row many represent
>> many different results -- do we show the union of tags for all the
>> rollup rows? Maybe we can use different colors / attributes to
>> represent "this tag exists on *some* of the results in this row" vs.
>> "this tag exists on *all* of the results in this row"...?
>> 4a. If the tags are listed as a column, they should also (of course)
>> be clickable so that if you click on them, you get the entire set of
>> results associated with that tag.
>> 4b. For every tag on a rollup row, it would be good to be able to say
>> "apply this tag to every result in this rollup row" (i.e., this tag
>> had previously only applied to *some* of the results in this rollup
>> row). This could be displayed as a little "+" icon next to the tag
>> name, or somesuch.
>> 4c. Similarly, for every tag, it would be good to have a "remove this
>> tag from every result in this row". This could be displayed as a
>> little "-" icon next to the tag name, or somesuch.
>> 4d. Care would need to be taken to ensure that users would not
>> accidentally click on "+" or "-" icons next to tag names, however.
>> 5. There should also be a simple way to:
>> - see all available tags (perhaps including some kind of
>> indication of how many results that tag represents)
>> - completely delete a tag from the entire database
>> 6. Tags may span multiple phases (install, build, run). If you click
>> on a tag that contains results on all three phases, what should
>> happen? I think it should be context-sensitive:
>> - If you are in a summary environment, you get a summary table
>> showing all relevant results.
>> - If you are in a single phase environment, you see only the
>> results in that phase (perhaps with a clickable icon to see the
>> entire summary table with all the tag's results).
>> 7. Lots of things can, by default, become tags. E.g., org name and
>> platform name can become default tags. I.e., results that are
>> submitted will automatically have the org name and platform name
>> added to the results as tags.
>> Jeff Squyres
>> Cisco Systems
>> mtt-devel mailing list
> mtt-devel mailing list