There are lots of ways to solve the problem via caching of results (either entire entities, ids, proxy objects that allow you to load by id, etc), depending upon your tolerance for potential inaccuracy in the page count. The reality for most tables, where the query isn't that complex, is that issuing a select count(*) before issuing a select ... offset...limit query really isn't that big a problem. It is likely a tiny fraction of the render time. Obviously there are cases where the query is slow, and in those cases, I tend to cache things in various ways. In the worst case, I'll issue an SQL query to select all ids and columns that wil be sortable, store that in a persistent location, and then just use offsets into my cache to render actual pages of results, issuing a straight query by ids rather than whatever complicated join I may have used to generate the results. That gets me up-to-date results for each row, even if the set of rows might be slightly stale. By selecting id and sortable column values, I can sort my cached list and ensure I get the correct results for the page. But this is all assuming you are dealing with a query that abslutely cannot be improved, under any circumstance, via changes to schema, hibernate caches, or network/storage infrastructure.
--sam On 12/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I am not sure if this is considered kosher . . . The ITablePagingState and ITableSortingState will be up to date prior to rendering - they encapsulate all of the data passed into the getCurrentPageRows() method. I could provide these object directly to my custom IBasicTableModel - it will invoke the service call once, and cache the results to fulfill any subsequent invocations to getRowCount() and getCurrentPageRows(). I don't know how modifying the tablesessionstate and tablesessionstore managers will impact this. Anyone have any thoughts? Carlos -----Original Message----- From: Fernandez, Carlos Sent: Monday, December 11, 2006 12:21 PM To: users@tapestry.apache.org Subject: IBasicTableModel - calling getRowCount() before getCurrentPageRows() I am using a variant of the contrib:table (it has pagination links above and below the table) to render DB search results. The search service is a proxy to a remote web service and uses Hibernate to prepare, execute and process the SQL query. In its current form the service supports pagination and expects an object that includes information related to the page requested (e.g. give me the next 10 matching rows starting at row 11). The service will then return results that not only contain the matching records (up to 10) but ALSO the total count of matching records. This was just fine for the original incarnation for the contrib:table that did not use the IBasicTableModel. However, now I have run into an issue relating to the separate getCurrentPageRows() and getRowCount() methods. It is my understanding that the order/frequency that these methods are called is based on the position of various components on the page. The way my pages are designed, getRowCount() will be called before getCurrentPageRows(). In order to handle the early getRowCount() call I currently make a request to the service API (e.g. get me 1 record starting at 1) to determine the count. When getCurrentPageRows() is called I make the page appropriate method call. To call this wasteful, might be an understatement. I could render the getRowCount() dependent components "after" the getCurrentPageRows() component and do some DHTML/CSS chicanery to visually reposition them. However, I would like to avoid this if possible, since anything other than vanilla HTML tends to be more error prone and more difficult to maintain. Am I missing something? Carlos --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
