[
https://issues.apache.org/jira/browse/WICKET-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mikhulya updated WICKET-2618:
-------------------------------------
Attachment: OptimizedDataProviderDecorator.java
AbstractDataProviderDecorator.java
There is a class from my application which already provide optimization
benefits to my application:
public abstract class CompoundDataView<T> extends DataView<T> {
protected CompoundDataView(String id, IDataProvider<T> dataProvider) {
super(id, new OptimizedDataProviderDecorator<T>(dataProvider));
}
protected CompoundDataView(String id, IDataProvider<T> dataProvider,
int itemsPerPage) {
super(id, new OptimizedDataProviderDecorator<T>(dataProvider),
itemsPerPage);
}
@Override
protected Item<T> newItem(String id, int index, IModel<T> model) {
return super.newItem(id, index, new
CompoundPropertyModel<T>(model));
}
@Override
protected int getViewSize() {
return internalGetRowsPerPage();
}
}
The important parts are usage of OptimizedDataProviderDecorator and overriding
of getViewSize.
This optimization is safe with current release of wicket (getViewSize is called
only from getItemModels which I can't override because of private class
CappedIteratorAdapter).
Of course it is safer to use internalGetRowsPerPage instead of getViewSize in
AbstractPageableView.getItemModels.
Notice, as soon as this optimization is integrated in wicket we can remove
"cachedItemCount" related methods from AbstractPageableView.
This optimization already saves me "count" sql in case when number of found
elements is less than number of rows per page.
Notice I provided a fix only for AbstractPageableView. (In my application I
don't use other subclasses of IPageable so it will take me much more time to
implement and test it).
Probably this optimization can be used for case when we ask for last page too.
Now it does't work for PagingNavigationLink, since here we call
pageable.setCurrentPage in onClick and IDataProvider.size is called prior to
"iterator" method.
> 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
> Attachments: AbstractDataProviderDecorator.java,
> OptimizedDataProviderDecorator.java
>
>
> 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.
