| 708f1c00df025e899c0ee8080fa4e81f71b8fa4c |
|
31-Mar-2010 |
jamesren <jamesren@592f7852-d20e-0410-864c-8624ca9c26a4> |
Support job keyvals and iteration attributes in the query_results CLI
Signed-off-by: James Ren <jamesren@google.com>
git-svn-id: http://test.kernel.org/svn/autotest/trunk@4359 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/ParameterizedField.java
|
| 3adac3671a998be8421238d3a08a7ffd2c3cbe1c |
|
13-Jan-2010 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
Display the text required for filtering on custom fields in the TKO UI.
Signed-off-by: Steve Howard <showard@google.com>
git-svn-id: http://test.kernel.org/svn/autotest/trunk@4113 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/ParameterizedField.java
|
| 8b0ea2285c1327a686ff0b6ab245915e7fd20094 |
|
23-Dec-2009 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
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
/external/autotest/frontend/client/src/autotest/tko/ParameterizedField.java
|
| d2b0c883cf9a8f98751d9bad684072cea85f2606 |
|
19-Oct-2009 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
Add almost everything necessary for UI support for including test attributes in table view.
This was almost straightforward. The one roadblock came with grouping support. I didn't bother including that for iteration results, but I did try to make it work here. Grouping is fine; unfortunately, grouping implies drilldown, and drilldown implies arbitrary filtering on test attributes, which requires a bit more sophisticated handling of which attribute fields we're requesting in each query (it's not just the ones we're viewing, but also any fields used in filtering). This isn't a terribly hard problem to solve, but doing it right will require some design changes, notably separating the fields in the view from the fields used in actual query, which will probably require making HeaderFields immutable to be done properly. I need to verify that this feature is high-enough priority to justify getting into all that, but I'd like to check in what I've got so far so I don't lose it.
To be clear, this doesn't actually add any user-visible changes yet.
Signed-off-by: Steve Howard <showard@google.com>
git-svn-id: http://test.kernel.org/svn/autotest/trunk@3866 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/ParameterizedField.java
|
| cb6ae7dca0f7eff64e3c9e413f0c30e008a2a6ae |
|
23-Sep-2009 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
Added ability to view iteration results in TKO Table View. The primary changes towards this end were:
* add IterationResultField, a ParameterizedField subclass for iteration results, and make TableView capable of generating and handling these fields
* add an IterationDataSource to make requests to get_iteration_views(), made TableView use this when iterations are selected
The feature is somewhat crude -- the name of the field is always something like "Iteration result 0" when it should really be something like "Iteration result: throughput" -- but I think it's a very functional first pass.
Unfortunately a lot of other changes were required, some quite ugly. This was due to two problems. First, TableView and HeaderSelect duplicate a lot of logic, but in slightly different ways. Unifying them will fix a lot of things. Second, there's a generally misguided use pattern field "names" and field "SQL names" in the code. That needs to be thought through and fixed.
Signed-off-by: Steve Howard <showard@google.com>
git-svn-id: http://test.kernel.org/svn/autotest/trunk@3761 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/ParameterizedField.java
|
| 227a7a1d0484dcfa4c6d996a1c10e95437d059ef |
|
18-Sep-2009 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
OK, one more refactoring -- this time, make TableView use HeaderFields (something I've wanted to do for a long time, there has been a TODO at the top of TableView for ages) and consolidate a lot more logic. Part of this was in the introduction of a new HeaderFieldCollection class, the rest was simple consolidation due to common use of HeaderField.
TableView and HeaderSelect still duplicate a lot of logic, sadly, although it's not immediately obvious from the code at this point. Eventually I'll fully consolidate those, but at this point I think I'm ready to implement the iteration view feature that I've been working towards the whole time.
Signed-off-by: Steve Howard <showard@google.com>
git-svn-id: http://test.kernel.org/svn/autotest/trunk@3753 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/ParameterizedField.java
|
| 2b50af17e5fa602821a8917bbb9fa1ddb1176ee3 |
|
14-Sep-2009 |
showard <showard@592f7852-d20e-0410-864c-8624ca9c26a4> |
Refactoring to extract and generalize all logic used for machine label headers. All the UI and presentation logic was tied closely to HeaderSelect, but the forthcoming feature to view iterations in table view will require the exact same logic in a different context. So in this change I extracted a generic superclass for MachineLabelField, ParameterizedField, and extracted all the relevant UI logic from HeaderSelect to a separate presenter, ParameterizedFieldListPresenter.
This is hopefully the last refactoring necessary before actually implementing the iteration view feature. And ideally, the test attribute view feature will follow on easily from that.
Signed-off-by: Steve Howard <showard@google.com>
git-svn-id: http://test.kernel.org/svn/autotest/trunk@3712 592f7852-d20e-0410-864c-8624ca9c26a4
/external/autotest/frontend/client/src/autotest/tko/ParameterizedField.java
|