[
https://issues.apache.org/jira/browse/WICKET-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793977#action_12793977
]
Johan Compagner commented on WICKET-2618:
-----------------------------------------
i think there will be a small problem with this
and we discussed this loads of times already...
the 2 methods we have:
Iterator<? extends T> iterator(int first, int count);
int size()
are called in this order if i am not mistaken:
int size()
Iterator<? extends T> iterator(int first, int count);
because the result of size() is used as for the parameter count...
But if you are able to extract it just from the list. Then size should just
call your list and return that size and that list is then used fo give the
iterator back in the iterator call.
> Don't call IDataProvider.size method when IDataProvider.iterator(first,
> count) returned the number of elements less than "count"
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-2618
> URL: https://issues.apache.org/jira/browse/WICKET-2618
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4.4
> Reporter: Michael Mikhulya
>
> IDataProvider has two mehtods:
> Iterator<? extends T> iterator(int first, int count);
> int size()
> which in many implementations do access to database.
> Normally iterator do SQL query with LIMIT and OFFSET, and size do SQL COUNT
> query.
> SQL COUNT is O(N) for most transactional databases (e.g. for postgresql) and
> so it is rather heavy.
> In some cases it is possible to avoid call to IDataProvider.size method.
> For example when "iterator" returned the number of elements less than
> acquired "count".
> This case appears in 90% in my application (whenever search is used normally
> number of found elements is less than number of elements on page).
> Also pgFouine shows me these queries as the most slow one. So I suggest to
> implement this optimization.
> First I though that appropriate place to implement it is AbstractPageableView
> class, but unfortunatelly not all IPageable classes extends this abstract
> class (for example DataTable doesn't do so).
> So I suggest to implement Decorator of IDataProvider and reuse it in
> DataViewBase, DataTable, ...
> If nobody see any problems with this suggestion I would like to implement it
> on my own.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
