Hi,
I got confused of proximity search. I am getting different results for the
queries TTL:"test device"~2 and TTL:"device test"~2
I expect same result for the above two queries. Is there any importance of
position of terms in a proximity query? Anybody please help me how lucene
exactly handles pr
Yes, I understood what you said. What I meant is, since i am using Lucene
2.1, I don't get the parse exception. So I thought it's working just like
using quotes.
Thanks,
Sonu
On 9/21/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
>
>
> : I checked the lucene converted syntax (using Query.toString
Thanks Hoss, for the reply. I am using Lucene 2.1.
I checked the lucene converted syntax (using Query.toString()) in both case
and found the second one actually not converting to proximity query.
"cat dog"~6 is converted to ABST:"cat dog"~4 and
(cat dog)~6 is converted to +ABST:cat +ABST:dog.
Tha
Hi,
I have a doubt on proximity search.
Is the query "cat dog"~6 same as (cat dog)~6 ?
I think both case will search for "cat" and "dog" within 6 words each other.
But I am getting different number of results for the above queries. The
second one may be the higher. Please clarify this.
Thanks,
Son
Hi,
Is there a way to distinct adjacent words between lines. I have problem
while searching a phrase. Since I am using stopword analyzer, the newlines
starting with stopwords are ignored in phrase search. So, such documents
comes as search result.
Please help me to solve this issue.
Thanks,
Sonu
Hi All,
I have problem when searching terms with wild card and NOT.
Simple Example is,
The query TITLE:(test1234 OR test567) return two results,
the query TITLE:(test1234 OR test567) AND NOT TITLE:(test1234) return one
result as my expectation,
the query TITLE:(test1234 OR test567) AND NOT TIT
Hi,
I am getting different results for the following queries.
1. ABST:"spring-elastic"^3 AND SPEC:"internal combustion"^2 OR
ABST:"cylinder"^3
2. SPEC:"internal combustion"^2 AND ABST:"spring-elastic"^3 OR
ABST:"cylinder"^3
I think the above two queries are similar and will give the sa
Thanks Ard. I think option 2 is good. I will try this.
On 7/13/07, Ard Schrijvers <[EMAIL PROTECTED]> wrote:
The SearchClient is obviously not aware of a changing index, so doesn't
know when it has to be reopened.
You can at least do the following:
1) you periodically check for the index fold
Hi,
I have SearchServer and SearchClient programs. The SearchServer
using RemoteSearchable
for binding the indices in servers . The SearchClient using
ParallelMultiSearcher for searching the indices. The problem is that I have
to restart the search servers for reflecting the index change in se
And you are correct, the UpdateDocument feature just conceals the
underlying delete/add functionality, it's not update-in-place.
Best
Erick
On 7/9/07, Sonu SR <[EMAIL PROTECTED]> wrote:
>
> Hi,
> My application using lucene index. The index documents having number of
> fie
Hi,
My application using lucene index. The index documents having number of
fields. We have around 5 million such documents. I have problem with regular
update of some of the fields in the document. So every update I need to
delete and index that updated documents. This is a huge task. I know from
sk...
Best
Erick
On 6/25/07, Sonu SR <[EMAIL PROTECTED]> wrote:
>
> Hi,
> Thanks for the response. The error is probably related with mysql. My
> appliation using mysql for keeping the status of indexed documents. So
> that
> duplication can be avoided. Some times the mysq
sulting.com/
- Original Message
From: Sonu SR <[EMAIL PROTECTED]>
To: java-user@lucene.apache.org
Sent: Monday, June 25, 2007 1:16:46 PM
Subject: Index issue with unexpected termination of program without
optimizing the index.
Hi,
I am using lucene in our site for index and search. We are creati
Hi,
I am using lucene in our site for index and search. We are creating the
index with large collection of documents (XML). The program some times
terminating without completing the index process. So the index optimization
and closing is not properly done. Is it to be optimized on the next index
14 matches
Mail list logo