The most reasonable solution is to use paging . You can display your range as in Google search page and each unit contains say ... 100 records . Then using iBATIS you can specify position and max records you want to retrieve . But , there are also improvement you can do in your query . For example if you use Oracle , you can do :
select * from ( select a.*, rownum rnum from ( YOUR_QUERY_GOES_HERE ) a where rownum <= MAX_ROWNUMBER ) where rnum >= MIN_ROWNUMBER And you can do similar thing in SQL Server too using SELECT TOP technique . -----Original Message----- From: Rick Reumann [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 10:46 AM To: Struts Users Mailing List Subject: Re: Dealing with large ResultSets?? On Mon, Mar 29, 2004 at 09:25:07PM -0300, Marcelo Epstein wrote: > How can I get more than 1000 rows of a table. > I am using display tag and I really don�t want 1000+ Objects. > What is the best practice to do that? > Does ORM models like Hibernate, Ibatis and others can help me? I'm huge fan of iBATIS, but from my understanding none of the ORM models actually help here too much and actually can make things worse (more memory intensive). I find it best in a case where you need a pagation type of thing (ie google-like previous next buttons, etc) to roll your own solution with JDBC. For example say you want to have the user browse through thousands of person records but they need to be sorted by person's hair color (I know stupid example:). Now since you are sorting by hair color you really can't work with a new select each time such as WHERE emp_id > (last spot you left off at). Since your huge list is sorted by hair color, the only way I've found to do it is to build a pagation type of mechanism where you actually query for all the records but in your ResultSet loop you only build the objects you need and break from the loop when you have enough. It gets a bit tricky since you have to keep track of when to start building as well (keep track of the last count position you left at it). Your best bet is to probably use a disconnected RowSet. This way you don't have to requery the db each time and you don't have to hold your typical connected ResultSet connection open to the db. You could then build the new sets of objects from this RowSet. The drawback to this is if the data changes a lot between the user's attempts to do prev and next. Even with a new query each time to the db, if the data changes, things can get ugly, so I'd opt for using a disconnected RowSet. Others may have better suggestions. -- Rick --------------------------------------------------------------------- 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]
