: Search we need to translate the Lucene style query into a more traditional
: Boolean query. So this is the opposite of the much discussed Boolean Query
: to Lucene Query conversion.
it should be possible to translate, but like many translations there will
be a small loss of information, speci
We have an application that performs searches against a Lucene based index
and also against a Windows Desktop Search based index.
For simple queries we'd like to offer our users a consistent interface that
allows them to build basic Lucene style queries using the 'MUST HAVE' (+),
'MUST NOT HAVE'
Perhaps you can explain in what way you want to make it more
powerful? There are possibilities to do:
1. Change the Similarity class (a call back mechanism)
2. Implement or extend Queries, Scorers, etc.
3. Others???
See http://lucene.apache.org/java/docs/scoring.html for some insights.
In oth
Ah, thanks for catching that. One of the pieces I did not finish...the
keyword analyzer was placeholder code.
I will take your comments into account and update the code.
I have some other pieces to polish as well. Previously, I extended and
built upon the original code, but I can't give it awa
Thanks for the tip.
One small improvement on the IndexAccessorFactory might be to allow user
to specify the Analyzer instead of using a default KeywordAnalyzer,
which of course will make your static init of the cached accessors
difficult unless you add more interfaces to the accessor to allow r
One final noteif you are using the IndexAccessor and you are only
accessing the index from one JVM, you can use the NoLockFactory and save
some sync cost there.
Jay Yu wrote:
Mark,
Great effort getting the original lucene index accessor package in
this shape. I am sure this will benefit
2.3-dev is not required. I'd have to look and see what is...I'd guess
around 2.1. I did program for java 1.5 though, but converting to 1.4
should be minimal work.
Jay Yu wrote:
Mark,
Great effort getting the original lucene index accessor package in
this shape. I am sure this will benefit a
Mark,
Great effort getting the original lucene index accessor package in this
shape. I am sure this will benefit a lot of people using Lucene in a
multithread env.
I have a quick question to ask you:
Do you have to use the core Lucene 2.3-dev in order to use the accessor?
I will take a look a
I have sat down and rewrote IndexAccessor from scratch. I copied in the
same reference counting logic, pruned some things, and tried to make the
whole package a bit simpler to use. I have a few things to do, but its
pretty solid already. The only major thing I'd still like to do is add
an optio
Hi every body:
I would like to know how to change the similarity function of lucene to
extends the posibilities of searching and make it more powefull. Have
somebody made this before ?
Could you help me please ? I don't know how complex might be this.
I hope you can help me.
Greetings
Ariel
Actually I am pretty sure that it is using Snowball for indexing too since
the results of the indexing in Luke do not include "nuts":
cheney
is
a
nut
i
hate
nut
Galactikuh wrote:
>
> Hi, Well I believe I did, but I am not positive. The code I use to set it
> up is below. Actually I'm not even r
I'd be very interested to see your test results and codes. Thanks!
Mark Miller wrote:
I sat down over the weekend and rewrote the code from scratch so that I
could improve and simplify it somewhat. I also did some testing of the
synch costs, and it is very insignificant compared to the total ti
Hi, Well I believe I did, but I am not positive. The code I use to set it up
is below. Actually I'm not even really sure how to specify which analyzer to
use for indexing using Hibernate Search. This may be a question for their
forum.
Thanks,
K
Patrick Turcotte-2 wrote:
>
> Hi,
>
> Did you use
On Sep 24, 2007, at 9:54 AM, Bogdan Ghidireac wrote:
On 9/24/07, Doron Cohen <[EMAIL PROTECTED]> wrote:
For an already optimized index calling optimize() is a no-op.
You may try this: after opening the writer and setting
compound=false, add
a dummy (even empty) document to the index, then
On 9/24/07, Doron Cohen <[EMAIL PROTECTED]> wrote:
>
> For an already optimized index calling optimize() is a no-op.
>
> You may try this: after opening the writer and setting compound=false, add
> a dummy (even empty) document to the index, then optimize(), and finally
> optionally remove the dumm
For an already optimized index calling optimize() is a no-op.
You may try this: after opening the writer and setting compound=false, add
a dummy (even empty) document to the index, then optimize(), and finally
optionally remove the dummy document.
Note that calling optimize() might be lengthy as
Hi,
I have an optimized compound index and I want to transform it to standard
format. I tried to optimize using the standard format but I had no luck.. Is
there another way ? I don't want to re-index because it will take several
days.
IndexWriter writer = new IndexWriter(args[0], new StandardAnal
I sat down over the weekend and rewrote the code from scratch so that I
could improve and simplify it somewhat. I also did some testing of the
synch costs, and it is very insignificant compared to the total time to
parse a query and run a search. I'll try and get around to posting the
code toni
18 matches
Mail list logo
