lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Staveley (Tom)" <rstave...@seseit.com>
Subject RE: MissingStringLastComparatorSource and MultiSearcher
Date Fri, 14 Jul 2006 17:50:47 GMT
Neat :-)

I was wanting to apply this to a field, which sorts on INT. Specifically I'm
trying to achieve reverse chronological sorting on a timestamp field, which
stores YYMMDDHHI (i.e. resolves to 10 minutes and doesn't handle centuries).
Missing timestamps are assumed to be "old" (i.e. should appear at the end). 

I could get this to sort on String and use
MissingStringLastComparatorSource, but would this not be less efficient than
sorting in INT??

Is there a case for...

public class Sorting {
  public static SortField getSortField(String fieldName, int type, boolean
reverse, boolean nullLast, boolean nullFirst) {
      // ...
  }
}

....and handling all feasible SortField types?

-----Original Message-----
From: Yonik Seeley [mailto:yseeley@gmail.com] 
Sent: 14 July 2006 18:30
To: java-user@lucene.apache.org
Subject: Re: MissingStringLastComparatorSource and MultiSearcher

On 7/14/06, Rob Staveley (Tom) <rstaveley@seseit.com> wrote:
> Chris Hostetter and Yonik's MissingStringLastComparator looks like a 
> neat way to specify where to put null values when you want them to 
> appear at the end of reverse sorts rather than at the beginning, but I
spotted the note...
>
>     // Note: basing lastStringValue on the StringIndex won't work
>     // with a multisearcher.
>
> Is that a show-stopper for MultiSearchers, or does it just mean that 
> it is a bit less efficient?
Short answer: it should work for 99.99999% of indicies :-)

That comment just related to the original code that's now commented out that
based the sort-value for missing values on the largest item in the index.

To fix that, missingValueProxy was added and defaulted to bigString.
That's what will be used to collate results in a multisearcher when the
field value is missing.  So this scheme will only fail if you have field
values that compare bigger than bigString (or whatever you pass in as
missingValueProxy).

See the code below:


  public static final String
bigString="\uffff\uffff\uffff\uffff\uffff\uffff\uffff\uffffNULL_VAL";

  private final String missingValueProxy;

  public MissingStringLastComparatorSource() {
    this(bigString);
  }

  /**
	 * Returns the value used to sort the given document.  The
	 * object returned must implement the java.io.Serializable
	 * interface.  This is used by multisearchers to determine how to
collate results from their searchers.
	 * @see FieldDoc
	 * @param i Document
	 * @return Serializable object
	 */

  /** Creates a {@link SortComparatorSource} that uses
<tt>missingValueProxy</tt> as the value to return from
ScoreDocComparator.sortValue()
   * which is only used my multisearchers to determine how to collate
results from their searchers.
   *
   * @param missingValueProxy   The value returned when sortValue() is
called for a document missing the sort field.
   * This value is *not* normally used for sorting, but used to create
   */
  public MissingStringLastComparatorSource(String missingValueProxy) {
    this.missingValueProxy=missingValueProxy;
  }




-Yonik
http://incubator.apache.org/solr Solr, the open-source Lucene search server

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

Mime
View raw message