#4 The `find_resultrow` chokes on Desktop matrix.
Closed 3 years ago by adamwill. Opened 4 years ago by lruzicka.

Hello, I have been trying to read the matrices with a script using wikitcms and when trying to read the Desktop matrix, the find_resultrow chokes on it with a traceback that there are more possible results. I have checked the matrix and indeed, the Printing test case has two rows, with the same testcase value and a different name.

What I am trying to achieve: I would like to read the matrices using a console script and CLI options to specify what info I want to get, for example:
script -t Desktop -s "Release-blocking desktops: <b>x86 / x86_64</b>" would return all test cases in the section -s and matrix -t. This works on other matrixes, but does not work on the Desktop matrix.

In my script, I am using the testcase field to specify which row I would like to find, plus the section field, because I was expecting that a test case is uniqe. The printing test case showed that testcase can also repeat and name cannot be used to look for the correct row.

How to proceed here? My use case is that a user can display the sections, testcases and columns and use that info to send the result in one single command. When this works, I would like to create a batch file with testcases, columns and results and report everything in one go. This would significantly speed up the reporting process for me.


This is what the testname arg is for. It filters on the 'name' of the result row. So something like find_resultrow(testcase='QA:Testcase_Printing_New_Printer', testname='real') should find only one row. (In fact, just find_resultrow(testname='real printer') would probably do the trick...)

BTW, did you find result.find_resultrows() yet? I don't know precisely the design you're going with, but it may well be useful to you.

Well, so theoretically, there could be someone using the script and they would not be able to browse the wiki, therefore I would like to be able to read the sections and testcases and provid:

  • I have created a dictionary that holds all the matrices divided by their type (Base, Desktop):
self.site = Wiki()
self.site.login()
self.available_matrices = {}
self.current = self.site.current_event
available = self.current.result_pages
for page in available:
    self.available_matrices[page.testtype] = page
  • From that dictionary, I am able to get the particular page on demand, and I can read all the sections:
    def get_matrix_sections(self, matrixtype):
        matrix = self.available_matrices[matrixtype]
        all_sections = matrix.sections
        sections = []
        for section in all_sections:
            if section['level'] == '4':
                sections.append(section['line'])
        return sections
  • And based on that list, I would like to see all test cases in one section:
    def get_section_testcases(self, matrixtype, section):
        matrix = self.available_matrices[matrixtype]
        all_rows = matrix.get_resultrows()
        rows = []
        for row in all_rows:
            if row.section == section:
                if row.testcase != row.name:
                    rows.append(f"{row.testcase} {row.name}")
                else:
                    rows.append(row.testcase)
        return rows
  • Here, I would like to pick a single test case and see all available result columns, so that I know into which I can save results. Here, I am getting the trouble, because from the above, I know the type of the matrix (Base, Desktop, Installation), I know the correct section, and I know the testcase and the testname. I am using this:
    def get_testcase_columns(self, matrixtype, section, test, name):
        matrix = self.available_matrices[matrixtype]
        if name:
            testcase = matrix.find_resultrow(test, section, testname=name)
        else:
            testcase = matrix.find_resultrow(test, section)
        columns = []
        for col in testcase.columns:
            if col != "Milestone" and col != "Test Case":
                columns.append(col)                                                                                    
        return columns

Normally, with Installation, Base matrix, I do not have any problems, but I do have problems with the Desktop matrix, because I am getting wikitcms.exceptions.TooManyError: More than one matching row found. even if section, testcase is specified and the section only has one of such testcases, for example QA:Testcase_audio_basic. It even does not work to specify the testname parameter and I am still getting the issue.

Maybe, there is something wrong with the matrix.

With this ugly hack (helped by @frantisekz) the script works even for the Desktop matrix.

--- /usr/lib/python3.8/site-packages/wikitcms/page.py
+++ /home/fanys/devel/relval-reporter/page.py
@@ -280,7 +280,8 @@
         if not rows:
             raise NotFoundError("Specified row cannot be found.")
         if len(rows) > 1:
-            raise TooManyError("More than one matching row found.")
+            return rows[0]
+            #raise TooManyError("More than one matching row found.")
         return rows[0]

     def update_current(self):

We realized that with find_resultrows(type, section, testcase) it still somehow had two rows of the apparently same test case. When we looked closer, it turned out that the problem is really caused by an ugly coincidence, that causes the function to traceback.

You are using the following piece of code:

        if len(rows) > 1 and section:
                rows = [r for r in rows if nrml(section) in nrml(r.section)]

which searches a normalized (lower case) substring in another string. That probably works fine but not on a matrix where one section is called Release-blocking desktops: <b>x86 / x86_64</b> and the other Non release-blocking desktops: <b>x86 / x86_64</b> and the first not only is an exact name of one section, but also a substring of the other section's name.

Shall we just rename the sections, so that the names are distinctive, or do you want to fix the method?

so - yes. well spotted. hrm. That's definitely a problem. I think maybe we can do both; I'll extend the bit at the bottom of find_resultrow which deals with a similar awkward case for test cases to also cover this awkward case for sections, but we can maybe also rename the sections as it'd still be a bit of a bear trap in that case, you'd have to search for the exact correct section name to make it work.

However, I think you're actually doing an unnecessary step here? The output of get_resultrows() is ResultRow instances already. Why not just have your get_section_testcases() store the entire ResultRow instance rather than just the testcase and testname? Then you wouldn't have to go and try to re-find the same ResultRow again later, you'd already have it. Obviously you wouldn't use the exact same get_testcase_columns() in that design, but I can't see the whole script so I can't say how you'd want to re-design it exactly.

BTW, your get_matrix_sections() also looks somewhat fragile to me. Page instances already have a results_sections property, is that not what you want?

BTW, have you looked at the code in relval which does more or less what you're trying to do here? I understand you're basically trying to do a more batch-y version of that, but that code still does have to get all the result rows in a page and then sort them out by section before it prompts you to enter a single result...

However, I think you're actually doing an unnecessary step here? The output of get_resultrows() is ResultRow instances already. Why not just have your get_section_testcases() store the entire ResultRow instance rather than just the testcase and testname? Then you wouldn't have to go and try to re-find the same ResultRow again later, you'd already have it. Obviously you wouldn't use the exact same get_testcase_columns() in that design, but I can't see the whole script so I can't say how you'd want to re-design it exactly.

Yeah, I think I could do it.

BTW, your get_matrix_sections() also looks somewhat fragile to me. Page instances already have a results_sections property, is that not what you want?

Will take a look. :crocodile:
Thanks a lot.

This should be resolved in the new 2.6.3 release by eae4362 , please let me know if not. Thanks!

Metadata Update from @adamwill:
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata