lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson" <>
Subject Re: No hits for longer search strings
Date Thu, 16 Oct 2008 13:39:38 GMT
query.toSting() is your friend, as is Luke's explain tab. I'd strongly
recommend that you try those, because I suspect that you're not
quite getting the search string you think.

That said, why use StandardAnalyzer for this? I'd recommend
KeywordAnalyzer instead (but watch the case).

The wildcard should be unnecessary since you're going for
exact matching.

But that query really seems like it should work. Could you post
your index and search code for this?

You can also use Luke to search your index, I'd really recommend
you try that too.


On Thu, Oct 16, 2008 at 6:14 AM, Chris Mannion <
> wrote:

> Hi All
> I have a bit of a puzzle in the Lucene system we've been running.  Part of
> our use involves inserting documents indexed by a unique key and then
> running exact searches to find that single document again later to display
> (the documents are also indexed by several other fields and used in a
> broader search, hence using Lucene).  I've just hit a strange bug lately
> where the documents are not being found under certain circumstances.  We've
> usually been indexing by unique ids about 12 characters in length, e.g.
> t10001c53421 and this has always worked fine, however when the id length is
> whacked up to 18, e.g. t10001c63241985103, the search never finds the
> documents.  I've used Luke which allows me to open the index for browsing
> and can see that the documents are definitely in the index and have the
> correct unique id values stored in there, so it seems to be a problem with
> the search.
> We're using a search string like (unique_id:(t10001c63241985103*) ) and
> standard analyzers to run the search.  Does anyone have any ideas why the
> increased search string length would affect things like this?
> --
> Chris Mannion
> iCasework and LocalAlert implementation team
> 0208 144 4416

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message