You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by "Rob Staveley (Tom)" <rs...@seseit.com> on 2006/07/14 19:13:11 UTC
MissingStringLastComparatorSource and MultiSearcher
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?
Re: MissingStringLastComparatorSource and MultiSearcher
Posted by Yonik Seeley <ys...@gmail.com>.
On 7/15/06, Rob Staveley (Tom) <rs...@seseit.com> wrote:
> The problem one is
> testSortingReverseNullFirst. My reckoning is that you are forward-sorting
> (or ascending-sorting if that's the right thing to say) the non-nulls.
OK, examples are probably easier to work with.
If we have a list of [A,null,Z] and we want that reverse sorted, then
we want nulls first, the result should be [null,Z,A].
If we were to use nullStringLastComparatorSource (which orders nulls
last in an *ascending* Lucene sort), the result would be [A,Z,null].
If we reverse this lucene sort, we get [null,Z,A], the desired result.
Ahhh, but in the code, we aren't doing the last reverse! That does look wrong.
return new SortField(fieldName,nullStringLastComparatorSource); // <-- !!!
Great catch! I think we never noticed because all of our usecases
called for nulls to sort last. I'll add a test to Solr for this case.
-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
RE: MissingStringLastComparatorSource and MultiSearcher
Posted by "Rob Staveley (Tom)" <rs...@seseit.com>.
> I haven't tried to run that test, but the non-null elements in your test
are ordered a bit funny for a reverse sort ;-)
:-) OK, Revision attached. With my QA-credibility at an all time low, could
you see what you make of the attached test? The problem one is
testSortingReverseNullFirst. My reckoning is that you are forward-sorting
(or ascending-sorting if that's the right thing to say) the non-nulls.
My feeling is that nullStringLastComparatorSource can only be applicable for
one of the four conditions and not two as you have it:
--------8<--------
public static SortField getStringSortField(String fieldName, boolean
reverse, boolean nullLast, boolean nullFirst) {
if (nullLast) {
if (!reverse) return new SortField(fieldName,
nullStringLastComparatorSource);
else return new SortField(fieldName, SortField.STRING, true);
} else if (nullFirst) {
if (reverse) return new SortField(fieldName,
nullStringLastComparatorSource); // <-- !!!
else return new SortField(fieldName, SortField.STRING, false);
} else {
return new SortField(fieldName, SortField.STRING, reverse);
}
}
--------8<--------
-----Original Message-----
From: Yonik Seeley [mailto:yseeley@gmail.com]
Sent: 15 July 2006 16:52
To: java-user@lucene.apache.org
Subject: Re: MissingStringLastComparatorSource and MultiSearcher
On 7/15/06, Rob Staveley (Tom) <rs...@seseit.com> wrote:
> Incidentally, Yonik, is the logic for
> org.apache.solr.search.Sorting#getStringSortField flawed? I don't see
> how the same comparator can be used for forward and reverse sorts for
> the non-null values.
The logic does cause a double-take at first glance :-) It's the combination
of the normal lucene string sort and MissingStringLastComparatorSource that
let you do all the permutations.
Keep in mind that "reverse" in the Solr schema sense is not quite the same
as "reverse" to a Lucene SortField.
> Methinks it is broken for reverse sorts where you specify nulls to
> appear first.
Let's take this case specifically...
First the semantics:
* @param nullFirst true if null should come first, regardless of sort
order
So if the sort is reversed, we want [null,null,Z,Y,...]
MissingStringLastComparatorSource orders null at the end in an ascending
sort. So if the sort is completely reversed (in the lucene sense), nulls
will be at the beginning like we specified.
> I added this test to TestMissingStringLastComparatorSource.java from
> http://issues.apache.org/jira/browse/LUCENE-406, which confirms my
> suspicions ...or confirms that I'd never get a job in QA:
:-)
I haven't tried to run that test, but the non-null elements in your test are
ordered a bit funny for a reverse sort ;-)
-Yonik
http://incubator.apache.org/solr Solr, the open-source Lucene search server
> --------8<--------
> public void testSortingReverseNullFirst() throws Exception {
>
> Hits result;
>
> boolean reverse = true;
> boolean nullLast = false;
> boolean nullFirst = true;
>
> Sort order = new Sort(Sorting.getStringSortField("data",
> reverse, nullLast, nullFirst));
>
> result = s.search(ALL, order);
>
> assertEquals("didn't get all", data.length, result.length());
>
> assertEquals("wrong order 2", "0", result.doc(2).get("id"));
> assertEquals("wrong order 3", "3", result.doc(3).get("id"));
> assertEquals("wrong order 4", "6", result.doc(4).get("id"));
> assertEquals("wrong order 5", "7", result.doc(5).get("id"));
> assertEquals("wrong order 6", "4", result.doc(6).get("id"));
> assertEquals("wrong order 7", "1", result.doc(7).get("id")); }
> --------8<--------
>
> -----Original Message-----
> From: Yonik Seeley [mailto:yseeley@gmail.com]
> Sent: 14 July 2006 21:59
> To: java-user@lucene.apache.org
> Subject: Re: MissingStringLastComparatorSource and MultiSearcher
>
> On 7/14/06, Rob Staveley (Tom) <rs...@seseit.com> wrote:
> > I was wanting to apply this to a field, which sorts on INT.
>
> The problem with int is that the FieldCache stores the values as an
> int[], and you can't tell when a value is missing.
>
> > 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??
>
> String sorting takes more memory, but the speed is the same. Local
> sorting with the FieldCache for strings is done via the ordinal value
> (no string compare is done, just int comparisons).
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: MissingStringLastComparatorSource and MultiSearcher
Posted by Yonik Seeley <ys...@gmail.com>.
On 7/15/06, Rob Staveley (Tom) <rs...@seseit.com> wrote:
> Incidentally, Yonik, is the logic for
> org.apache.solr.search.Sorting#getStringSortField flawed? I don't see how
> the same comparator can be used for forward and reverse sorts for the
> non-null values.
The logic does cause a double-take at first glance :-)
It's the combination of the normal lucene string sort and
MissingStringLastComparatorSource that let you do all the
permutations.
Keep in mind that "reverse" in the Solr schema sense is not quite the
same as "reverse" to a Lucene SortField.
> Methinks it is broken for reverse sorts where you specify nulls to appear
> first.
Let's take this case specifically...
First the semantics:
* @param nullFirst true if null should come first, regardless of sort order
So if the sort is reversed, we want [null,null,Z,Y,...]
MissingStringLastComparatorSource orders null at the end in an
ascending sort. So if the sort is completely reversed (in the lucene
sense), nulls will be at the beginning like we specified.
> I added this test to TestMissingStringLastComparatorSource.java from
> http://issues.apache.org/jira/browse/LUCENE-406, which confirms my
> suspicions ...or confirms that I'd never get a job in QA:
:-)
I haven't tried to run that test, but the non-null elements in your
test are ordered a bit funny for a reverse sort ;-)
-Yonik
http://incubator.apache.org/solr Solr, the open-source Lucene search server
> --------8<--------
> public void testSortingReverseNullFirst() throws Exception {
>
> Hits result;
>
> boolean reverse = true;
> boolean nullLast = false;
> boolean nullFirst = true;
>
> Sort order = new Sort(Sorting.getStringSortField("data", reverse,
> nullLast, nullFirst));
>
> result = s.search(ALL, order);
>
> assertEquals("didn't get all", data.length, result.length());
>
> assertEquals("wrong order 2", "0", result.doc(2).get("id"));
> assertEquals("wrong order 3", "3", result.doc(3).get("id"));
> assertEquals("wrong order 4", "6", result.doc(4).get("id"));
> assertEquals("wrong order 5", "7", result.doc(5).get("id"));
> assertEquals("wrong order 6", "4", result.doc(6).get("id"));
> assertEquals("wrong order 7", "1", result.doc(7).get("id"));
> }
> --------8<--------
>
> -----Original Message-----
> From: Yonik Seeley [mailto:yseeley@gmail.com]
> Sent: 14 July 2006 21:59
> To: java-user@lucene.apache.org
> Subject: Re: MissingStringLastComparatorSource and MultiSearcher
>
> On 7/14/06, Rob Staveley (Tom) <rs...@seseit.com> wrote:
> > I was wanting to apply this to a field, which sorts on INT.
>
> The problem with int is that the FieldCache stores the values as an int[],
> and you can't tell when a value is missing.
>
> > 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??
>
> String sorting takes more memory, but the speed is the same. Local sorting
> with the FieldCache for strings is done via the ordinal value (no string
> compare is done, just int comparisons).
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: MissingStringLastComparatorSource and MultiSearcher
Posted by "Rob Staveley (Tom)" <rs...@seseit.com>.
Incidentally, Yonik, is the logic for
org.apache.solr.search.Sorting#getStringSortField flawed? I don't see how
the same comparator can be used for forward and reverse sorts for the
non-null values.
Methinks it is broken for reverse sorts where you specify nulls to appear
first.
I added this test to TestMissingStringLastComparatorSource.java from
http://issues.apache.org/jira/browse/LUCENE-406, which confirms my
suspicions ...or confirms that I'd never get a job in QA:
--------8<--------
public void testSortingReverseNullFirst() throws Exception {
Hits result;
boolean reverse = true;
boolean nullLast = false;
boolean nullFirst = true;
Sort order = new Sort(Sorting.getStringSortField("data", reverse,
nullLast, nullFirst));
result = s.search(ALL, order);
assertEquals("didn't get all", data.length, result.length());
assertEquals("wrong order 2", "0", result.doc(2).get("id"));
assertEquals("wrong order 3", "3", result.doc(3).get("id"));
assertEquals("wrong order 4", "6", result.doc(4).get("id"));
assertEquals("wrong order 5", "7", result.doc(5).get("id"));
assertEquals("wrong order 6", "4", result.doc(6).get("id"));
assertEquals("wrong order 7", "1", result.doc(7).get("id"));
}
--------8<--------
-----Original Message-----
From: Yonik Seeley [mailto:yseeley@gmail.com]
Sent: 14 July 2006 21:59
To: java-user@lucene.apache.org
Subject: Re: MissingStringLastComparatorSource and MultiSearcher
On 7/14/06, Rob Staveley (Tom) <rs...@seseit.com> wrote:
> I was wanting to apply this to a field, which sorts on INT.
The problem with int is that the FieldCache stores the values as an int[],
and you can't tell when a value is missing.
> 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??
String sorting takes more memory, but the speed is the same. Local sorting
with the FieldCache for strings is done via the ordinal value (no string
compare is done, just int comparisons).
-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
RE: MissingStringLastComparatorSource and MultiSearcher
Posted by "Rob Staveley (Tom)" <rs...@seseit.com>.
> The problem with int is that the FieldCache stores the values as an int[],
and you can't tell when a value is missing.
I take it that missing values appear as 0, which would be an illegal value
for my case, but I accept your point that it isn't good enough for a general
solution.
> String sorting takes more memory, but the speed is the same.
Bearing in mind that 0 would have to be illegal for an int and 0.0f would
have to be illegal for a float, I would thinking of implementing the
SortField thus (plagiarising your design) to conserve memory...
Here's the SortField.FLOAT implementation (as a code snippet) - the
SortField.INT implementation is analogous, but uses
FieldCache.DEFAULT.getInts:
--------8<--------
case SortField.FLOAT:
return new SortField(fieldName,
new SortComparatorSource() {
private final Comparable missingValueProxy;
// Instance initialiser - this is how you do Ctors
in anonymous classes
{
missingValueProxy = new
Float(missingValueGoesLast ? Float.MAX_VALUE : Float.MIN_VALUE);
}
public ScoreDocComparator newComparator(IndexReader
reader,String fieldName) throws IOException {
// Canonical representation of the String
(???)
final String field = fieldName.intern();
// Get the index of the field
final float index[] =
FieldCache.DEFAULT.getFloats(reader,field);
return new ScoreDocComparator() {
public final int compare (final
ScoreDoc i, final ScoreDoc j) {
final float fi =
index[i.doc];
final float fj =
index[j.doc];
// 0 is the magic position
of null
if (fi==fj) return 0;
if (fi==0.0f) return 1;
if (fj==0.0f) return -1;
return fi < fj ? -1 : 1;
}
public Comparable sortValue (final
ScoreDoc i) {
float f = index[i.doc];
return (0.0f == f) ?
missingValueProxy : new Float(f);
}
public int sortType() {
return SortField.CUSTOM;
}
};
}
} // SortComparatorSource
); // Custom SortField for SortField.FLOAT
--------8<--------
By the way, this copies fieldName.intern() from your implementation, but I
confess I couldn't understand why that's used. Also, does the type returned
by ScoreDocComparator.sortType() relevant here? I made this
SortField.CUSTOM, but I'm not sure if it wouldn't be better for it to be
SortField.FLOAT in the above.
-----Original Message-----
From: Yonik Seeley [mailto:yseeley@gmail.com]
Sent: 14 July 2006 21:59
To: java-user@lucene.apache.org
Subject: Re: MissingStringLastComparatorSource and MultiSearcher
On 7/14/06, Rob Staveley (Tom) <rs...@seseit.com> wrote:
> I was wanting to apply this to a field, which sorts on INT.
The problem with int is that the FieldCache stores the values as an int[],
and you can't tell when a value is missing.
> 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??
String sorting takes more memory, but the speed is the same. Local sorting
with the FieldCache for strings is done via the ordinal value (no string
compare is done, just int comparisons).
-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
Re: MissingStringLastComparatorSource and MultiSearcher
Posted by Yonik Seeley <ys...@gmail.com>.
On 7/14/06, Rob Staveley (Tom) <rs...@seseit.com> wrote:
> I was wanting to apply this to a field, which sorts on INT.
The problem with int is that the FieldCache stores the values as an
int[], and you can't tell when a value is missing.
> 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??
String sorting takes more memory, but the speed is the same. Local
sorting with the FieldCache for strings is done via the ordinal value
(no string compare is done, just int comparisons).
-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
RE: MissingStringLastComparatorSource and MultiSearcher
Posted by "Rob Staveley (Tom)" <rs...@seseit.com>.
:-) You're right! It remains the case that INT and FLOAT equivalents of
MissingStringLastComparatorSource would be useful for the reverse reverse
(i.e. not reverse) case :-)
-----Original Message-----
From: Chris Hostetter [mailto:hossman_lucene@fucit.org]
Sent: 15 July 2006 00:24
To: java-user@lucene.apache.org
Subject: RE: MissingStringLastComparatorSource and MultiSearcher
: 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).
for the record, MissingStringLastComparatorSource isn't really needed in
this case. If a missing timestamp field should be interpreted as "old"
then normal Lucene "reverse" sorting (either String or int) should work fine
for a reverse chronological sort -- because in normal String sorting "null"
is low, and (i'm 99% sure) in int sorting "null" is assigned a value of 0.
In both cases, your "old" docs will wind up where you want them.
MissingStringLastComparatorSource comes in handy when you want docs without
a timestamp value to appear at the end of your list *regardless* of wether
the user selected "oldest first" or "newest first"
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: MissingStringLastComparatorSource and MultiSearcher
Posted by Chris Hostetter <ho...@fucit.org>.
: 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).
for the record, MissingStringLastComparatorSource isn't really needed in
this case. If a missing timestamp field should be interpreted as "old"
then normal Lucene "reverse" sorting (either String or int) should work
fine for a reverse chronological sort -- because in normal String sorting
"null" is low, and (i'm 99% sure) in int sorting "null" is assigned a
value of 0. In both cases, your "old" docs will wind up where you want
them.
MissingStringLastComparatorSource comes in handy when you want docs
without a timestamp value to appear at the end of your list *regardless*
of wether the user selected "oldest first" or "newest first"
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: MissingStringLastComparatorSource and MultiSearcher
Posted by "Rob Staveley (Tom)" <rs...@seseit.com>.
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) <rs...@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
Re: MissingStringLastComparatorSource and MultiSearcher
Posted by Yonik Seeley <ys...@gmail.com>.
On 7/14/06, Rob Staveley (Tom) <rs...@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