[jira] Updated: (WICKET-2618) Don't call IDataProvider.size method when IDataProvider.iterator(first, count) returned the number of elements less than "count"

["Michael Mikhulya (JIRA)" <ji...@apache.org>]

     [ 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.