Humm.
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.
-- Josh
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
WHERE
(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.
-Ethan
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
tagging:
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-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
_______________________________________________
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
