[
https://issues.apache.org/jira/browse/WICKET-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651278#action_12651278
]
Stefan Fussenegger commented on WICKET-1784:
--------------------------------------------
Bruno,
I don't think the purpose of this ticket is to follow a pattern. It's about a
*major* performance hog. If you'd be accessing Lucene through Wicket using an
IDataProvider, you'd realize that you are performing every query twice (except
those with an empty resultset). And hitting your search index 10 or 20 times a
second is quite a difference.
Did you read my comment
(https://issues.apache.org/jira/browse/WICKET-1784?focusedCommentId=12650587#action_12650587)
above? I suggested to only change the implementation of PagingNavigationLink
to allow a custom Repeater that implements IPageable (in order to use the
default Navigation component - or is it the Navigator? I always confuse them
...).
As mentioned above, PagingNavigationLink.getPageNumber() checks whether the
chosen page number (chosen by clicking such a link) is allowed. It does that
by calculating the current number of pages (i.e. fetches the size). This check
isn't needed, as any current IPageable implementation checks that special case
itself (which is a Good Thing (tm)).
Therefore, the change would be quite trivial and would have a tremendous effect
for Lucene-based applications at the same time.
Hence, +1 - or may I give more than that? ;)
Btw, fetching data and total amount at the same time is possible with MySQL too
(See
http://dev.mysql.com/doc/refman/5.1/en/information-functions.html#function_found-rows).
> Enhance IDataProvider to support applications using the Transfer Object J2EE
> pattern
> ------------------------------------------------------------------------------------
>
> Key: WICKET-1784
> URL: https://issues.apache.org/jira/browse/WICKET-1784
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.3.3, 1.4-M3
> Environment: Wicket 1.3.3 and 1.4-M3
> Reporter: R. Goodwin
> Assignee: Igor Vaynberg
> Attachments: wicket-paging-experiment.zip
>
>
> In some environments searches are performed in 'single call' fashion, using a
> transfer object.
> E.g. two queries performed by the data services tier before returning
> combined results to the UI tier:
> i. Query for paged search results
> ii. Query for a 'count' value representing total possible results
> The contract between DataView and IDataProvider does not support a 'single
> call' environment as the give/take relationship between these classes is
> biased towards DataView.
> DataView expects IDataProvider to provide it's size before providing
> IDataProvider with its offset and count.
> * DataView may have good reasons for needing size before it can provide
> offset/count.
> * But IDataProvider has equally good reasons for needing offset/count before
> it can provide size.
> The circular dependency:
> 1. DataView calls IDataProvider.size()
> 2. IDataProvider cannot return size as it cannot start a query until it
> receives offset/count from DataView
> 3. These it does not receive until DataView calls IDataProvider.iterator()
> later on
> Others who experienced this problem (with CODE examples):
> * http://www.nabble.com/IDataProvider-and-Hibernate-Search-td15546101.html
> * http://www.mail-archive.com/[EMAIL PROTECTED]/msg14266.html
> ---
> The suggested solution of caching the combined search results and count value
> does not work if the search cannot begin until offset and count are
> available. And writing a custom DataView is not feasible either time wise as
> I understand that it cannot be done without needing to write a number of
> other classes too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
