Re: [T5] GridDataSource: why call getAvailableRows before prepare?
I have the exact same problem/question? When I call prepare myself and update my availableRows parameter. Once the getAvailableRows run, the parameter is reseted by itself. How to use GridDatasource the correct way? Franz Amador wrote: I'm starting to use Grid to display the paged, sortable results of a Hibernate query, so I'm implementing GridDataSource. I was dismayed to see that getAvailableRows gets called before prepare. This means that I have to run my query twice: once to count the total rows (when getAvailableRows gets called), and again to do the sorting and get the correct page (when prepare gets called). If, instead, prepare got called first, then I could do the sorting and page extraction and get the total number of results all in one query (just add count(*) to the columns being returned). You might ask, how can the system know the page size to ask for when calling prepare if it hasn't called getAvailableRows first? No problem: just ask for the first full page and have prepare return the number of rows it actually found. (Or add a getter for that information.) For fast queries, running them twice isn't that great a sin, but for slow queries, such as in a user-specified search page, running them twice when you don't really have to seems extravagant to me. -- View this message in context: http://www.nabble.com/-T5--GridDataSource%3A-why-call-getAvailableRows-before-prepare--tp19616074p26108742.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5] GridDataSource: why call getAvailableRows before prepare?
This could be naive since I don't use the grid, but can't you just store the results in a property of the page/component when getAvailableRows is called? It sounds like you can successfully run the query twice so you must have the info you need at that point. Use a getter method for your query that caches the results? I imagine you must be holding on to them already in order to use them while rendering the page I must be missing something. On Mon, Sep 22, 2008 at 2:18 PM, Franz Amador fgama...@yahoo.com wrote: I'm starting to use Grid to display the paged, sortable results of a Hibernate query, so I'm implementing GridDataSource. I was dismayed to see that getAvailableRows gets called before prepare. This means that I have to run my query twice: once to count the total rows (when getAvailableRows gets called), and again to do the sorting and get the correct page (when prepare gets called). If, instead, prepare got called first, then I could do the sorting and page extraction and get the total number of results all in one query (just add count(*) to the columns being returned). You might ask, how can the system know the page size to ask for when calling prepare if it hasn't called getAvailableRows first? No problem: just ask for the first full page and have prepare return the number of rows it actually found. (Or add a getter for that information.) For fast queries, running them twice isn't that great a sin, but for slow queries, such as in a user-specified search page, running them twice when you don't really have to seems extravagant to me. -- View this message in context: http://www.nabble.com/-T5--GridDataSource%3A-why-call-getAvailableRows-before-prepare--tp19616074p19616074.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- -- TheDailyTube.com. Sign up and get the best new videos on the internet delivered fresh to your inbox. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5] GridDataSource: why call getAvailableRows before prepare?
Em Thu, 29 Oct 2009 16:00:01 -0200, Josh Canfield j...@thedailytube.com escreveu: This could be naive since I don't use the grid, but can't you just store the results in a property of the page/component when getAvailableRows is called? That's a nice idea. I would just store the results in a property of the GridDataSource implementation, not in the page itself. The idea of having getAvailableRows() invoked before prepare() is that, in the prepare() method, you only fetch the row that will be shown in a given grid rendering. This way, if you have a search that returns 1000 rows but you're only showing 25 per page, you fetch these 25 rows, not 1000. My GridDataSource implementation, in its getAvailableRows() method, executes a query that only returns a count(*), not the rows themselves. They're fetched in prepare(). -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
[T5] GridDataSource: why call getAvailableRows before prepare?
I'm starting to use Grid to display the paged, sortable results of a Hibernate query, so I'm implementing GridDataSource. I was dismayed to see that getAvailableRows gets called before prepare. This means that I have to run my query twice: once to count the total rows (when getAvailableRows gets called), and again to do the sorting and get the correct page (when prepare gets called). If, instead, prepare got called first, then I could do the sorting and page extraction and get the total number of results all in one query (just add count(*) to the columns being returned). You might ask, how can the system know the page size to ask for when calling prepare if it hasn't called getAvailableRows first? No problem: just ask for the first full page and have prepare return the number of rows it actually found. (Or add a getter for that information.) For fast queries, running them twice isn't that great a sin, but for slow queries, such as in a user-specified search page, running them twice when you don't really have to seems extravagant to me. -- View this message in context: http://www.nabble.com/-T5--GridDataSource%3A-why-call-getAvailableRows-before-prepare--tp19616074p19616074.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]