Come up with something that represents your pager and holds the information necessary to reconstruct your query. It will need to keep track of: Search string + Criteria + Current Page + Page Size + maybe some more stuff.
I'm working on building a pager right now... but it's a "dirty" solution. My "design muscles" are lazy tonight. In additon, my DAOs have alternate methods for retrievals that yield collections for returning just a certain set of objects based on the page number, page size, and criteria. I calculate the startAtIndex and endAtIndex "on-the-fly" based off the current page and page size. ... don't poke the broker into the session ;-) Close it as soon as you've completed retrieving your data. If my "design muscles" wake up and I arrive at a design I'm especially proud of for the pager, I'll be sure to post it here. It would basically embody the above logic. You could cache the number of pages expected in your pager object and use that to know how far you can go ... Stephen Ting wrote: >Hello, > >I have some question regarding PersistenceBroker usage. > >How to implement it in OJB in the following scenario, i plan to >implement pagination for the db enquiry system. > >1. To get the total number of rows from a query. > > SELECT COUNT(*) FROM inventory WHERE part_no LIKE '%cement%' > Say it will return back 100 records. > >2. Then, another query will get data by setting the absolute position of >the resultSet. say from record 1 to 10 another from 11 - 20 and etc > > SELECT * FROM inventory WHERE part_no LIKE '%cement%' > > >>From my observation of the OJB doc and test case. I found that for item >1,it can be done by broker.getCount() and for item 2, >it can be done by setting the start and end index for the query before >the broker excute the query. > >Should i store the persistenceBroker create at first in the session >scope, so that when user click from page to page they will use the same >persistenceBroker to retrieve the records or i will have to create new >persistenceBroker each time user request for new page. what is the >overhead for the both scenario and which is the better solution. I >believe you all will have other solution that can solve the above >mentioned scenario. > >Thanks in advance > >regards, > >Stephen > -- Eddie Bush -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
