lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Rayguy <iscjraym...@yahoo.com>
Subject RE: Iterernal Document Numbers
Date Thu, 01 Apr 2004 21:26:43 GMT
Tim,

Thanks for your reply.  Believe me, the sorting in 1.4
is greatly welcomed, but I don't think it fits my
particular needs.  My criteria for the sort can change
without notice on the fly, and I'd rather not have to
recreate the index to accomdate this.

Using 1.3 I played with including the sort criteria
(in integer form) in the index, and had every query
include a range in conjunction with a custom
similarity that essentially made the "sort" field the
heaviest criteria.  This worked, although I had
concerns about the speed (including a range in every
query that spanned all documents), and I still had the
issue of how to change scores easily.  I went as far
as to hack up a tool that could modify the index
itself and change the termfreq for my sorting field,
but this is not the road I want to go down! :)

So, assuming that sort as implemented in 1.4 doesn't
work for me, my original question still stands.  Do I
have to worry about merges that occur as documents are
added, or do I only have to rebuild my array after
optimizations?  Or, alternatively, how did everyone
sort before 1.4?

Joe

--- Tim Jones <TJones@hoovers.com> wrote:
> the 1.4 release contains sorting code that sorts 
> similarly to your description.  You can get the
> latest 1.4 release here:
> 
> http://cvs.apache.org/dist/jakarta/lucene/v1.4-rc2/
> 
> look at org.apache.lucene.search.Sort
> 
> 
> > -----Original Message-----
> > From: Joe Rayguy [mailto:iscjraymond@yahoo.com]
> > Sent: Thursday, April 01, 2004 11:58 AM
> > To: lucene-user@jakarta.apache.org
> > Subject: Iterernal Document Numbers
> > 
> > 
> > Hi,
> > 
> > I apologize if this has been answered before, but
> is
> > it safe to design an application that sorts hits
> using
> > an external array based on each hit's internal
> > document ID?  It seems simple enough to rebuild
> the
> > array after an optimization, but what about merges
> > that
> > occur in the course of adding documents?  If I
> plan on
> > adding documents every minute or so recreating
> this
> > array with each addition doesn't seem feasible.
> > 
> > Is there a recommended way to handle such an array
> for
> > sorting results?
> > 
> > Thanks.
> > 
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail - More reliable, more storage, less
> spam
> > http://mail.yahoo.com
> > 
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> lucene-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> lucene-user-help@jakarta.apache.org
> > 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> lucene-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> lucene-user-help@jakarta.apache.org
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org


Mime
View raw message