Currently, my Lucene search code allows the user to specify
which fields are searched ...I have now had a request to enhance
the code to allow the users to specify that certain
searchfields contain one value and other ( or all other ) fields
contain a different value.
In Luke I can do following
On 7/15/06, Erick Erickson <[EMAIL PROTECTED]> wrote:
I'm assuming that you only add to your index,
and don't optimize it after deletions or do anything else that would change
the document IDs
That won't quite work... add() after delete() can change document ids
because it can cause a segment m
Does it make any sense at all to pre-calculate and permanently store date
range filters for each day? I'm assuming that you only add to your index,
and don't optimize it after deletions or do anything else that would change
the document IDs Lucene assigns AND you index each day's mail sequentially
On 7/15/06, Rob Staveley (Tom) <[EMAIL PROTECTED]> 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,nu
> 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 reck
The following little program should do the job for
you.
/* HTMLTextStripper.java
* July 15, 2006
*/
import java.io.*;
import org.xml.sax.*;
import org.xml.sax.helpers.*;
import javax.xml.parsers.*;
/** HTMLTextStripper
* @author Charles Bell
* @version July 15, 2006
*/
public class HTM
On 7/15/06, Rob Staveley (Tom) <[EMAIL PROTECTED]> 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
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 tes
who know?
2006/7/15, James liu <[EMAIL PROTECTED]>:
yes,it can do...but now work for chinese search. english search is ok.
and how can i fix it?
2006/7/15, Doron Cohen <[EMAIL PROTECTED]>:
> > Hits hits = searcher.search(qp.Query(queryStr));
>
> I think it should be qp.parse(String query)
> It's not allways faster ... it really depends on how many matching terms
there are in your range.
Does the cached RangeFilter's performance drop off relative to RangeQuery
with a large number of matches then?
> Wether you should cache all RangeFilters depends largely on how often you
plan on r
> 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 sorti
:-) 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:[EMAIL PROTECTED]
Sent: 15 July 2006 00:24
To: java-user@lucene.ap
12 matches
Mail list logo
