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
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