Hi Marc Can you give some statistics about the amount of data you are indexing ? Do you not think requering for pagination will increase the time taken for bringing the hits. Rather than bringing the entire hits once in the memory then displaying it as and when the user is clicking on the next button. It would be very kind of you if you give me a detailed view about this..
Regards, Kinnar -----Original Message----- From: Marc Dauncey [mailto:[EMAIL PROTECTED] Sent: Friday, April 28, 2006 8:25 PM To: java-user@lucene.apache.org Subject: Re: Efficiently paginating results. Yes, I was thinking about index updates. Getting a different result set when you go back to a previous page might be an issue - could always cache each page as its opened rather than the entire result set. --- Hannes Carl Meyer <[EMAIL PROTECTED]> wrote: > Hi Marc, > > I'm using this method for a web-application. I'm > storing only the > current viewable set of documents in the session and > re-query if the user > scrolls to the next page. This method is pretty fast > and has a minimal > session- and processing-footprint. But, if your > index is changed during > scrolling and that affects the query and you're > re-querying, you will > maybe get confused about new docs :-) > > Hannes > > Marc Dauncey schrieb: > > I read somewhere recently (maybe even on this > list) a > > recommendation to requery each time for successive > > pages as this avoids some of the complexity > involved > > in session management. Whats peoples view of this? > > > > Marc > > > > > > --- karl wettin <[EMAIL PROTECTED]> wrote: > > > > > >> 27 apr 2006 kl. 20.44 skrev Jean Sini: > >> > >>> Our application presents search results in a > >>> > >> paginated form. > >> > >>> We were unable to find Searcher methods that > would > >>> > >> return, say, 'n' > >> > >>> (typically, 10) hits after a start offset 'k'. > >>> > >>> So we're currently using the Hits collection > >>> > >> returned by > >> > >>> Searcher.search, > >>> and using its Hits.doc(i) method to get the ith > >>> > >> hit, with i between > >> > >>> k and > >>> k+n. Is that the most efficient way to do that? > Is > >>> > >> there a better > >> > >>> way (e.g. > >>> some form of Filter on the query itself)? > >>> > >> You probably want to do it just the way you do. > >> > >> But cache the Hits somehow. Perhaps in a session, > >> perhaps globally > >> in /your/ searcher. Perhaps the session points > at > >> the global cache > >> so it doesn't change within a session when you > flush > >> the cache on > >> index update. > >> > >> > >> > > > --------------------------------------------------------------------- > > > >> To unsubscribe, e-mail: > >> [EMAIL PROTECTED] > >> For additional commands, e-mail: > >> [EMAIL PROTECTED] > >> > >> > >> > > > > > > > > > > > ___________________________________________________________ > > > Yahoo! Photos - NEW, now offering a quality print > service from just 7p a photo > http://uk.photos.yahoo.com > > > > > --------------------------------------------------------------------- > > 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] > > Send instant messages to your online friends http://uk.messenger.yahoo.com --------------------------------------------------------------------- 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]
