[
https://issues.apache.org/jira/browse/WICKET-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
R. Goodwin updated WICKET-1784:
-------------------------------
Description:
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.
was:
In some environments searches are performed in 'single call' fashion,
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.
Summary: Enhance IDataProvider to support applications using the
Transfer Object J2EE pattern (was: Break circular dependency between DataView
and IDataProvider (size versus offset/count))
> 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
>
> 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.
