Multi-page results within a set are randomly ordered

XMLWordPrintable

    • Type: Bug
    • Resolution: Fixed
    • Priority: Medium
    • 3.1
    • Affects Version/s: 2.6.1 Pro
    • Component/s: None
    • 2.06

      1. If a 'find' returns more than one page of results, those results are split over several pages.

      2. If the grouping (the sort column) does not provide sufficient differentiation (eg., many of the issues are of the same priority), the ordering within the sorted group is random.

      3. Consequently, when paging from one page to the next, issues are re-ordered and sometime INFORMATION CAN BE LOST because clicking "Next>>" will not show you all the issues.

      This happens because the natural ordering of issues is not preserved in between pages. On page 1 of 3, issues might be ordered as such:

      400
      430
      576
      320

      But, when I view the second page, this natural ordering changes within the sorted group. If the group does not provide a great deal of order (such as the date), the second page might select this result set:

      430
      400
      320
      576

      If the result set is less than one page long, this doesn't matter. But if the result set is longer than a page, the random ordering can mean that some issues never appear while paging through the results, or that some issues appear more than once.

      (You can try this by clicking on the "2.7 Pro" milestone, which is three pages long, and pay close attention to the order of the results. What is the last item on the first page? Go to the second page. Does that item appear again? Go back to the first page... odds are, it's not at the bottom of the page anymore... it might not even be on the page!).

      This can be solved by adding a secondary sort to all queries. I would suggest sorting by <priority>,<issue#> (in other words, always do a secondary sort on the <issue#>).

        1. p1.jpg
          186 kB
          Zacharias J. Beckman
        2. p2.jpg
          208 kB
          Zacharias J. Beckman
        3. p3.jpg
          186 kB
          Zacharias J. Beckman

              Assignee:
              Unassigned
              Reporter:
              Zacharias J. Beckman
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved: