Open MPI logo

MTT Devel Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

From: Josh Hursey (jjhursey_at_[hidden])
Date: 2007-08-29 09:45:56


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
> (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-devel_at_[hidden]
> _______________________________________________
> mtt-devel mailing list
> mtt-devel_at_[hidden]