[ http://jira.codehaus.org/browse/DISPL-14?page=comments#action_42059 ]
Dennie de Lange commented on DISPL-14: -------------------------------------- Cross post from DISPL-134, Sorry, I want this discussion to get active and this issue has more viewers. Hello, I am looking over the different issues regarding paging with large resultsets. There are many different solutions for it. I like to know which direction displaytag is going and if any work on it is being done currently. I couldn't find any pointers in the code or documentation. I.m.h.o. it should be kept simple and configurable in the tag. I would be bad to ask the developer to implement a different list to support custom subselects, not all developers have access to the List. An attribute like virtualsize makes sence. Maybe we should close the other issues and leave one issue open to this issue. If any help is required I'll try to make some extra time. Thanks in advance. Greetz Dennie > Smart Paging > ------------ > > Key: DISPL-14 > URL: http://jira.codehaus.org/browse/DISPL-14 > Project: DisplayTag > Type: Improvement > Components: Paging/Sorting > Versions: 1.0 RC2 > Reporter: fabrizio giustina > Assignee: fabrizio giustina > Attachments: OptimizedPaginationIteration.1.0-RC2.zip, > OptimizedPaginationIteration.zip, > displaytag-1.0-rc1-pdf_paging_exclude_columnhref.diff, dt_pdf_paging.diff, > dt_pdf_paging_java.zip > > > ==== > 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. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ displaytag-devel mailing list displaytag-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/displaytag-devel
