tree d1bffbd08532f350099016c29a917dc1baef5fd4
parent 27a3ae0446e476839f9b16992063819129df1016
author showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> 1261596183 +0000
committer showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> 1261596183 +0000

Overhaul how we deal with related data in TKO -- test labels, test attributes, machine labels, and iteration results.

This has proven one of the trickiest areas of TKO.  The first foray into this area was machine label headers, an early feature request implemented in a pretty ad-hoc manner in spreadsheet view which allowed them to be used as header fields.  (Ironically, this was closest to the right approach on the server side, but I didn't appreciate it at the time.  The original client-side implementation was a mess.)  Next was filtering on test attributes and test labels, implemented with the include_labels, exclude_labels, include_attributes_where, and exclude_attributes_where options.  This server-side implementation supported filtering but not viewing, grouping or sorting at all.  Furthermore, even the filtering support was weak -- it only supporting ORing of inclusion requests and ANDing of exclusion requests.  The client-side implementation was still pretty messy but was moving towards correctness.  Finally, support was recently added for viewing iteration results in table view, but 
 grouping and filtering were excluded since they would've been very difficult to fit into the design.  This was again a limited server-side approach, though the client-side implementation continued improving, albeit still using the trouble "generator items" in the mutliple list selector widget.

When I started working on support for test iterations and attributes in TKO table view, I finally hit upon the right server-side approach: specify the attributes that you're interested in, have the server perform a separate JOIN for each one, so that there's now a new column for each one, NULL if the attribute didn't exist and having the attribute's value if it did.  Once it's created as a normal column, the user can do selection, grouping, sorting and filtering using the regular mechanisms.  Everything just works.  (For labels, it's slightly different, since whether or not a label is attached to a test is a boolean value.  I opted to have the column's value be either NULL or the name of the label.)

Well, not quite perfectly.  MySQL lets us define column aliases in a SELECT which are then usable in GROUP BY and ORDER BY.  They aren't however, usable in the WHERE clause, because certain select expressions may not exist at the time the WHERE is applied.  (Our expressions happen to be fine, but MySQL will have none of it.)  There's absolutely no way I can see to define aliases for use in the WHERE clause.  And unfortunately, our current interface allows users to provide a WHERE clause directly, so we can't perform translations or substitutions.  As a result, filtering must be performed a little differently for these fields.  You can't just say <field_name> = "<value>", like you can for most fields.  For test attributes and iteration results, you say <field_name>.value = "<value>".  For test labels and machine labels, you say <field_name>.id IS [NOT] NULL.

The first part of this CL is changing the server to use this new approach.  get_test_views() now accepts test_label_fields, test_attribute_fields, machine_label_fields, and iteration_result_fields parameters, which allow the user to add extra fields based on these data types.

At the same time, I've changed how the TKO web clients deals with these data types in a way that mirrors the new way of handling these features on the server.  There is now a global widget for adding custom fields based on any of the four data types.  Once one is created, it can be used just like any other field in spreadsheet view, table view, and the global condition.  This vastly simplifies most pieces of the code that previously dealt with these features, and it greatly expands the available space of features.  Where we formerly had spreadsheet grouping/filtering on machine labels, table viewing of iteration results, and limited filtering on test labels and attributes, we now have viewing, grouping sorting, and filtering on all four.

High-level changes involved:

Server side
* added code to TestViewManager to handle the new options for creating fields, documented them, and documented that these options are supported and the rest are deprecated (we can probably delete them but we should check, they might be in use)
* added thorough unit tests for all of the above.  on a side note, i discovered a neat feature of SQLite where you can add any function you've defined at a callable function from SQL statements.  I used this to add some functions emulating MySQL-only functions.  This could be used to good effect elsewhere, but this CL is big enough :)
* got rid of now-obsolete code for machine_label_headers option and iteration views

Client side:
* made HeaderFields immutable.  Mutable HeaderFields turned out to be way too much of a nightmare.  Users can specify values for ParameterizedFields at creation time, and if they want to modify them, they can delete and add.
* made all parts of the application (namely SpreadsheetView (both header selectors), TableView, and CommonPanel) use a single global HeaderFieldCollection
* changed ParameterizedFieldListPresenter to handle the new job of allowing creation and deletion of any kind of ParameterizedField.  This new widget replaces the label/attribute filtering widget in the CommonPanel -- I got rid of all the code for that widget.
* removed the now-obsolete code for "generator items" in the MultiListSelectPresenter.
* finally made TableView use HeaderSelect.  Since HeaderSelect plays a more significant role and it's role is more unified, it made sense to finally do this (TableView was previously duplicating logic from HeaderSelect, which was only used in SpreadsheetView).  Since the HeaderSelect used in TableView is much simpler than the one used in SpreadsheetView, I extracted a new class SpreadsheetHeaderSelect, using composition rather than inheritance (it didn't really follow an is-a relationship).

Signed-off-by: Steve Howard <showard@google.com>


git-svn-id: http://test.kernel.org/svn/autotest/trunk@4049 592f7852-d20e-0410-864c-8624ca9c26a4