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. ContactDataProviderTest.java
        4 kB
        bernard
      2. PagingPage.java
        3 kB
        bernard

        Activity

        bernard created issue -
        Hide
        bernard added a comment -

        PagingPage.java, ContactDataProviderTest.java

        Show
        bernard added a comment - PagingPage.java, ContactDataProviderTest.java
        bernard made changes -
        Field Original Value New Value
        Attachment PagingPage.java [ 12422593 ]
        Attachment ContactDataProviderTest.java [ 12422594 ]
        Igor Vaynberg made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Assignee Igor Vaynberg [ ivaynberg ]
        Fix Version/s 1.4.7 [ 12314560 ]
        Fix Version/s 1.5-M1 [ 12313078 ]
        Resolution Fixed [ 1 ]
        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...
        Igor Vaynberg made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        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...
        Igor Vaynberg made changes -
        Issue Type Bug [ 1 ] Improvement [ 4 ]
        Assignee Igor Vaynberg [ ivaynberg ]
        Fix Version/s 1.4.7 [ 12314560 ]
        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)
        Igor Vaynberg made changes -
        Fix Version/s 1.5-M2 [ 12315237 ]
        Fix Version/s 1.5-M1 [ 12313078 ]
        Igor Vaynberg made changes -
        Fix Version/s 1.5-M3 [ 12315329 ]
        Fix Version/s 1.5-M2 [ 12315237 ]
        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
        Jeremy Thomerson made changes -
        Fix Version/s 1.5-M4 [ 12315483 ]
        Fix Version/s 1.5-M3 [ 12315329 ]
        Martin Grigorov made changes -
        Fix Version/s 1.5-M4 [ 12315483 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        108d 8h 22m 1 Igor Vaynberg 05/Feb/10 03:54
        Resolved Resolved Reopened Reopened
        43m 2s 1 Igor Vaynberg 05/Feb/10 04:37

          People

          • Assignee:
            Unassigned
            Reporter:
            bernard
          • Votes:
            3 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:

              Development