The following comment has been added to this issue:
Author: James Schopp
Created: Fri, 15 Oct 2004 2:09 PM
Body:
While I don't want to "boil the ocean" with requirements, this solution doesn't meet
all needs (at least mine...). For example :
1) our backend is a mainframe that feeds us data in sets - you cannot know the full
record size without first reading all the sets, which I don't want to have to do.
2) the size of each set is controlled by the backend, not DT. So, although DT might
display 10 records per page, we are forced to get data back in 100-record sets. 1 data
set can back 10 DT pages. This means each page-hit does NOT coincide with a DB-hit.
3) the "marker" for fetching the next data set is returned to us by the previous set -
it is not sufficient just to know what page you are on. In order to get the "marker"
for the 10th page, you must first traverse the previous 9.
4) One of the databases we are using is MS SQL Server, which although it does have the
"top" select attribute to get the first 100, it cannot for instance grab the middle
100. To do this we rely on sorting the data by specific columns, the specify a ">"
where clause to remove the first X records, then use the top specifier to get the
first Y records. This has the overall effect of getting the middle N records, but
seriously limits our sorting capability.
I have found yet another solution (which does NOT exclude the solution you all
provide):
We have gotten around alot of these issues by creating a "PagingList" List
implementation which has the ability to load and unload data as necessary. So, you if
iterate the list, it will load data as needed, but then unload say records 1-100 if
you are currently on record 200. It also caches the markers mentioned above, so that
after the first sequential access, it is randomly accessible from then on. The markers
are definable by the back end, so if the system is MySQL, it could be as simple as
"page number", but if the backend is a mainframe, it could be a complex object.
I have implemented this list with DT, and it only required a few changes to the DT
source - which are in reality just optimizations. The changes are only to stop DT from
constantly iterating over the entire list, which in my case caused the entire dataset
to be loaded (very large).
THESE OPTIMIZATIONS ARE THEREFORE BENEFICIAL TO ALL LISTS, not just my "special"
lists. This means it *should* also work
The optimizations only "kick in" if the table is NOT full-list sorted, and the object
is actually of type "List" (since it appears that in theory DT can make tables out of
other collections too).
I made these ontop of 1.0 rc1
I will attach them below.
---------------------------------------------------------------------
View this comment:
http://jira.codehaus.org/browse/DISPL-14?page=comments#action_25435
---------------------------------------------------------------------
View the issue:
http://jira.codehaus.org/browse/DISPL-14
Here is an overview of the issue:
---------------------------------------------------------------------
Key: DISPL-14
Summary: Smart Paging
Type: Improvement
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: DisplayTag
Components:
Tag Library
Versions:
1.0 RC2
Assignee:
Reporter: fabrizio giustina
Created: Sat, 25 Sep 2004 4:39 AM
Updated: Fri, 15 Oct 2004 2:09 PM
Description:
====
imported from sf tracker
id 1026408
submitted by Ivan Markov - ivan_markov
http://sourceforge.net/tracker/index.php?func=detail&group_id=73068&atid=536613&aid=1026408
====
Smart Paging
------------
Smart paging refers to the ability of DT to deal with large lists of data. The problem
with the current DT approach is that:
a) The whole (potentially large) list of data has to be created for the DT tag,
occupying lots of memory.
b) If the list contains 1000s of records, populated with data from a SQL Server (99%
of the cases, I would say), you have huge network traffic between the webapp and the
server. Our code is especially useful for servers like Oracle & MySQL which have
built-in means to return only a subset of DB cursor's content.
There's one solution + one enhancement on the forums already (issue #1013526), so why
a third one?
We didn't like in the earlier proposal that it deals with intercepting DT's request
and parsing DT's request parameters, which seems a bit hacky. Also, we avoid the
complications of parsing parameters when there is > 1 table tag on the page. Not to
mention that the older proposal does not deal with full list sorting, or does it?
Instead, we introduced a new interface, DataProvider. It has two methods:
- List getData(int unsortedOffset, int unsortedLength, int recordOffset, int pageSize,
String sortedColumnName, boolean sortOrderAscending);
- int getDataCount();
The first two parameters unsortedOffset & unsortedLength are only needed for
supporting DT's setOffset()/setLength() features.
In our patch, DataProvider is used as a "callback" into user's code. The user is
supposed to implement the two methods of this interface.
The code in TableTag and its supporting classes is changed in a way that, for each
response where DT is rendered,
a) One call is issued to DataProvider.getDataCount(), which retrieves the total number
of rows in the data set (needed for DT to calculate the number of pages).
b) One call is issued to DataProvider.getData(), with the current page, page size &
sorting info.
A sample implementation of user-supplied JDBC DataProvider follows, in pseudocode.
Some JDBC exception handling stuff omitted.
<%
request.setAttribute("list", new DataProvider() {
List getData(int unsortedOffset, int unsortedLength, int recordOffset, int
pageSize, String sortedColumnName, boolean sortOrderAscending) {
Connection con = <app-specific way to get connection>;
PreparedStatement ps = con.prepareStatement("SELECT * FROM MyTable ORDER BY ?
LIMIT ?, ?"):
ps.setString(1, sortedColumnName);
ps.setInt(2, recordOffset);
ps.setInt(3, pageSize);
//etc..
ResultSet rs = con.execute();
return <app-specific way of getting List from ResultSet; Maybe use RowSet
instead of List?>;
}
int getDataCount() {
Connection con = <app-specific way to get connection>;
PreparedStatement ps = con.prepareStatement("SELECT count(*) FROM
MyTable"):
ResultSet rs = con.execute();
rs.next();
return rs.getInt(1);
}
});
%>
(DataProvider implementation code can be moved to Struts Controller/Action, depending
on the MVC framework used, in order not to polute the JSP code with Java scriptlets.)
Smart Paging Compatibility
--------------------------
We tried to change DT's code so that all older code to continue to work.
If user has provided an old-style List containing all the data, DT will automatically
wrap it with a ListDataProvider.
Current DT functionality (full-list sorting, decorations, multiple tables per page,
etc.) is supported, except for these two cases:
a) Full list(not page) sorting by a decorated column - sorting is done without
regarding the decorator.
b) Full list sorting by a column with no "property" attribute (static or implicit
object call via servlet) - no sorting is performed at all.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
displaytag-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/displaytag-devel
