Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@www.apache.org Received: (qmail 16634 invoked from network); 25 May 2004 14:47:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 25 May 2004 14:47:34 -0000 Received: (qmail 18176 invoked by uid 500); 25 May 2004 14:47:45 -0000 Delivered-To: apmail-jakarta-lucene-dev-archive@jakarta.apache.org Received: (qmail 18135 invoked by uid 500); 25 May 2004 14:47:44 -0000 Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Developers List" Reply-To: "Lucene Developers List" Delivered-To: mailing list lucene-dev@jakarta.apache.org Received: (qmail 18119 invoked by uid 98); 25 May 2004 14:47:44 -0000 Received: from erik@ehatchersolutions.com by hermes.apache.org by uid 82 with qmail-scanner-1.20 (clamuko: 0.70. Clear:RC:0(128.143.59.147):. Processed in 0.018939 secs); 25 May 2004 14:47:44 -0000 X-Qmail-Scanner-Mail-From: erik@ehatchersolutions.com via hermes.apache.org X-Qmail-Scanner: 1.20 (Clear:RC:0(128.143.59.147):. Processed in 0.018939 secs) Received: from unknown (HELO postfix.mail.ehatchersolutions.com) (128.143.59.147) by hermes.apache.org with SMTP; 25 May 2004 14:47:44 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by postfix.mail.ehatchersolutions.com (Postfix) with ESMTP id 4B613727DDA for ; Tue, 25 May 2004 10:47:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <003f01c4425e$90fe23f0$ac7ba8c0@diderot> References: <003f01c4425e$90fe23f0$ac7ba8c0@diderot> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <0AEAB458-AE5A-11D8-89A1-000393A564E6@ehatchersolutions.com> Content-Transfer-Encoding: quoted-printable From: Erik Hatcher Subject: Re: RE : ReSorting Date: Tue, 25 May 2004 10:44:36 -0400 To: "Lucene Developers List" X-Mailer: Apple Mail (2.613) X-Spam-Rating: hermes.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On May 25, 2004, at 9:45 AM, Rasik Pandey wrote: > Erik, > >> No, re-sorting without re-running a search is not possible (at >> least >> not easily). > > It would be nice to be able to provide different views of Hits based=20= > on different sort criteria without touching the index for a second=20 > time as the "desired" results have already been returned. What do you=20= > mean by "not easily"? Actually, after thinking about it a bit more, it would be impossible to=20= re-sort Hits after a search. The new sorting infrastructure is=20 extremely efficient with resources, and does not keep more than it=20 needs to around. So you could not change the field it is sorted on=20 without re-searching. If all you were going to do is reverse a sort, you could walk the Hits=20= backwards instead of re-sorting or re-searching. I still say your best bet (and surely not slow?) is to re-search. >> Why not just re-run a search with a different >> sort? > > Of course that is one solution, but maybe not the most solid. As=20 > theoretically, an index at time A is not necessarily the same index at=20= > time B. If the use case requires the most update data from the index=20= > then your solution would suffice, but if a quasi snap-shot of a set of=20= > results needed to be kept, it wouldn=92t solve the problem. Again, this is not correct if you keep the IndexReader or IndexSearcher=20= around. Erik --------------------------------------------------------------------- To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: lucene-dev-help@jakarta.apache.org