Wicket
  1. Wicket
  2. WICKET-2532

Pageable Views call IDataProvider.size() more than once

    Details

    • Type: Improvement Improvement
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.4.1
    • Fix Version/s: None
    • Component/s: wicket
    • Labels:
      None
    • Environment:
      All

      Description

      IDataProvider.size() is typically an expensive database operation. It is called twice in typical Pageable View scenarios although Wicket makes attempts to avoid that. In addition, the first call is premature from the application perspective because it is made while the the requested page position is not yet known.

      How to reproduce:

      Drop in the attached files into the Wicket examples application and run:

      repeaters|Paging DataView Example - builds on previous to demonstrate paging and page navigation

      Otherwise I am running against a wall with IDataProvider.size() and AbstractPageableVew because I can't find any way to get the page position at the same time when IDataProvider.size() is called. Support of paging of results of unknows size is impossible without this information. Please refer to Google search results paging - that is the kind of paging we need.

      1. PagingPage.java
        3 kB
        bernard
      2. ContactDataProviderTest.java
        4 kB
        bernard

        Activity

        Hide
        bernard added a comment -

        PagingPage.java, ContactDataProviderTest.java

        Show
        bernard added a comment - PagingPage.java, ContactDataProviderTest.java
        Hide
        Igor Vaynberg added a comment -

        not as easy as i thought...this may need a bigger rework...

        Show
        Igor Vaynberg added a comment - not as easy as i thought...this may need a bigger rework...
        Hide
        Igor Vaynberg added a comment -

        there is no good way to do this without altering existing behavior, so moving to 1.5.

        size() is only called twice when a navigation link is used to page through the table, so not that much overhead...

        Show
        Igor Vaynberg added a comment - there is no good way to do this without altering existing behavior, so moving to 1.5. size() is only called twice when a navigation link is used to page through the table, so not that much overhead...
        Hide
        bernard added a comment -

        Igor,

        I stumbled over this when I tried to write a read-ahead buffering IDataProvider without separate count queries for resultsets that are (effectively) of unknown size. I could not do it, and this has nothing to do with this bug.

        I think my attempts failed because iterator(int first, int count) is always called after size(), and iterator.hasNext() is never called above the size limit.

        That means in my case that if the user clicked on the last link of a paging navigator, then I was completely stuck without the chance to read ahead a new buffer from the database because the user was already on the last link and he would not get a chance to move beyond that. I was too late to increase size() because iterator.hasNext() was not called even though there was more data redy to be fetched into the next buffer.

        The last page link seems to kill the whole idea. I was really frustrated because everything else worked.

        Do you have any ideas whether this case could be supported in a future release?

        Show
        bernard added a comment - Igor, I stumbled over this when I tried to write a read-ahead buffering IDataProvider without separate count queries for resultsets that are (effectively) of unknown size. I could not do it, and this has nothing to do with this bug. I think my attempts failed because iterator(int first, int count) is always called after size(), and iterator.hasNext() is never called above the size limit. That means in my case that if the user clicked on the last link of a paging navigator, then I was completely stuck without the chance to read ahead a new buffer from the database because the user was already on the last link and he would not get a chance to move beyond that. I was too late to increase size() because iterator.hasNext() was not called even though there was more data redy to be fetched into the next buffer. The last page link seems to kill the whole idea. I was really frustrated because everything else worked. Do you have any ideas whether this case could be supported in a future release?
        Hide
        Igor Vaynberg added a comment -

        we will try to work on it. unfortunately a "navigate to last page" link is a very commonly used feature so i dont think it is possible to remove.

        Show
        Igor Vaynberg added a comment - we will try to work on it. unfortunately a "navigate to last page" link is a very commonly used feature so i dont think it is possible to remove.
        Hide
        bernard added a comment -

        Thanks very much.

        Currently there is no sulution at all, and I would like to be humble with respect to what kind of possible solution of this problem.

        Removing "navigate to last page" would definitely solve it but you might find better solutions, too.

        What about letting the framework call iterator.hasNext() one more time even after the size() number is exhausted, pushing the dataprovider to fetch a new buffer and increase size? This would work only if Wicket would adjust to the new size, too.

        If there was a parameter in the size() call, or callback that the DataProvider could call to find the requested page position that would be great.

        Unfortunately this info must be available, and I found that
        a) it isn't at the time of the first size() call which is the subject of the bug
        b) the call I used to get the requested position called back into size() so I ended up with infinite recursion.
        (This jira text box is one character wide on my Firefox 3.6, I can't see while I am typing)

        Show
        bernard added a comment - Thanks very much. Currently there is no sulution at all, and I would like to be humble with respect to what kind of possible solution of this problem. Removing "navigate to last page" would definitely solve it but you might find better solutions, too. What about letting the framework call iterator.hasNext() one more time even after the size() number is exhausted, pushing the dataprovider to fetch a new buffer and increase size? This would work only if Wicket would adjust to the new size, too. If there was a parameter in the size() call, or callback that the DataProvider could call to find the requested page position that would be great. Unfortunately this info must be available, and I found that a) it isn't at the time of the first size() call which is the subject of the bug b) the call I used to get the requested position called back into size() so I ended up with infinite recursion. (This jira text box is one character wide on my Firefox 3.6, I can't see while I am typing)
        Hide
        Jeremy Thomerson added a comment - - edited

        just to add a comment here. the inmethod grid allows tables of unknown size. we could look at how it does it, although there are significant differences between the two.

        also, see WICKET-579

        Show
        Jeremy Thomerson added a comment - - edited just to add a comment here. the inmethod grid allows tables of unknown size. we could look at how it does it, although there are significant differences between the two. also, see WICKET-579

          People

          • Assignee:
            Unassigned
            Reporter:
            bernard
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:

              Development