Hello,
I am using the AnalyzingInfixSuggester for my suggester, and trying to
get the apostrophe to work correctly (highlighter and search).
I am adding a field to my main index for the suggester with the
apostrophe included:
document.add(new StoredField
Hi,
I have a question regarding AnalyzingInfixSuggester.
Suppose I have an indexed term with the word: Lucene
And I query Luc!!!
Even In this case I would want lucene to suggest me Lucene, because at the
analyzer level I am handling cleaning the query part. The Analyzer would remove
)
.addTokenFilter(LowerCaseFilterFactory.class)
.addTokenFilter(SuggestStopFilterFactory.class).build();
On 23 February 2018 at 14:57, jawad lamrayah <jlh1...@gmail.com> wrote:
> Hi,
>
> I have one question about AnalyzingInfixSuggester behavior.
> In fact when I sea
Hi,
I have one question about AnalyzingInfixSuggester behavior.
In fact when I search with two terms, if only the second term is found, I
have the auto complete with the suggestions containing the second term.
If only the first term is found, there is no suggestion.
e.g:
new market -->
Hi,
Im using the AnalyzingInfixSuggester for my autocomplete.
So i have a singleton object where I am opening the suggester and keeping the
references. Many threads are accessing these references and performing
searches. But what i want to do is that my underlying directory where the index
Huber gregh3...@gmail.com wrote:
Hello,
I am extending AnalyzingInfixSuggester for use with my suggester where I
change the query to be a AND rather than an OR in the finishQuery(..)
method.
ie
/**
* Subclass can override this to tweak the Query before searching.
*/
protected
Hello,
I am extending AnalyzingInfixSuggester for use with my suggester where I
change the query to be a AND rather than an OR in the finishQuery(..)
method.
ie
/**
* Subclass can override this to tweak the Query before searching.
*/
protected Query finishQuery(Builder in, boolean
Hello,
I am trying to use multiple contexts on the
org.apache.lucene.search.suggest.analyzing.AnalyzingInfixSuggester but
there is a mistake on the CONTEXTS_FIELD_NAME, the
BooleanClause.Occur.SHOULD needs to be BooleanClause.Occur.MUST. ( see
below)
I noticed that its been fixed on the trunk
Well this is by design really. Ie, the original intent here (4.10.3)
is to return a suggestion if it has any of the specified contexts.
Maybe for 4.10.3 you could subclass AIS and override finishQuery to
rewrite the SHOULD to MUST in your case?
Mike McCandless
http://blog.mikemccandless.com
That change (a new feature, to let you control MUST vs SHOULD for each
context) was done with
https://issues.apache.org/jira/browse/LUCENE-6050
But it's a new feature, not a bug ... and 4.10.x is for bug fixes
only, so I don't think we will backport it.
Mike McCandless
, but the
principle is the same.
Cheers, Oli
*From:*Michael Breu [mailto:michael.b...@arctis.at]
*Sent:* Monday, October 27, 2014 9:21 AM
*To:* java-user@lucene.apache.org
*Subject:* Re: real infix suggester, not AnalyzingInfixSuggester
Hello Oliver,
I already had a look
), schiff
(boat), etc.
So I would like to support searches like *schiff* to suggest
Donaudampfschifffahrtsgesellschaft.
I have mistakenly tried for the AnalyzingInfixSuggester, however this
does not do what I expect, because it does prefix matches to tokens, but
no infix matches.
I tried to adapt
Have you considered combining the AnalyzingInfixSuggester with a German
decompounding filter? If you break compound words into their
constituent parts during analysis, then the suggester will be able to do
what you want (prefix matches on the word-parts). I found this project
with a quick
decompounding (you probably do).
Cheers, Oli
-Original Message-
From: Michael Sokolov [mailto:msoko...@safaribooksonline.com]
Sent: Monday, October 27, 2014 7:23 AM
To: java-user@lucene.apache.org
Subject: Re: real infix suggester, not AnalyzingInfixSuggester
Have you considered combining
...@safaribooksonline.com
Montag, 27. Oktober 2014 12:22
Have you considered combining the AnalyzingInfixSuggester with a
German decompounding filter? If you break compound words into their
constituent parts during analysis, then the suggester will be able to
do what you want (prefix matches
, October 27, 2014 7:23 AM
To: java-user@lucene.apache.org
Subject: Re: real infix suggester, not AnalyzingInfixSuggester
Have you considered combining the AnalyzingInfixSuggester with a
German decompounding filter? If you break compound words into their
constituent parts during analysis
, not AnalyzingInfixSuggester
Hello Oliver,
I already had a look into the AnalyzingSuggester before. I was not able to spot
the location where it generates the prefixes. It works with some path analysis
based on automaton (both for analysis and query).
It is not really clear to me how to extend this automaton
On 8/14/2014 5:48 PM, Michael McCandless wrote:
I think we should expose commit? Can you open an issue?
I will
And fix the NPEs to be a more informative exc? E.g.
IllegalStateException w/ a reasonable message ...
You should be able to init AIS on a previously built suggester, not
.build()
I opened LUCENE-5889. While I was writing that I remembered another
gap: it would be useful to have a delete() method. Callers might like to
be able to include or exclude terms based on their frequency, which can
change over time, and at the very least when a term no longer occurs in
the
I've been using AIS, and I see that it now has support for incremental
updates, which is great! I'm looking forward to getting suggestions from
newly-added documents without the need to rebuild the entire suggester
index. I've run into a few problems though, and I want to see if there
is a
I think we should expose commit? Can you open an issue?
And fix the NPEs to be a more informative exc? E.g.
IllegalStateException w/ a reasonable message ...
You should be able to init AIS on a previously built suggester, not
.build() it every time your application starts...
Mike McCandless
(sourceindex))
val searcher = new IndexSearcher(reader)
val suggester = new AnalyzingInfixSuggester(Version.LUCENE_44,new
File(/tmp/lucene/1374619766134),analyzer,analyzer,3)
val indReader = searcher.getIndexReader
val maxid = indReader.maxDoc()
for(id-0 until maxid){
id+1
AnalyzingInfixSuggester(Version.LUCENE_44,new
File(/tmp/lucene/1374619766134),analyzer,analyzer,3)
val indReader = searcher.getIndexReader
val maxid = indReader.maxDoc()
for(id-0 until maxid){
id+1
val doc = searcher.doc(id)
val keys = Array[TermFreqPayload](new
Right, you need those classes from src/test to compile the test case.
Just run ant test -Dtestcase=AnalyzingInfixSuggesterTest from the
lucene/suggest directory.
Also, you cannot pass a real index to the suggester: it builds the
index itself, when you call the .build method. This index is
Hello i am trying to build the example but TermFreqPayload
and TermFreqPayloadArrayIterator are missing from suggest package also how
to pass to suggester.build method real index instead of mock words so it
can rebuild it.
using lucene 4.4
2013/7/26 vonPuh fonPuhendorf vonpuhfonpuhend...@gmail.com
Hello i am trying to build the example but TermFreqPayload
and TermFreqPayloadArrayIterator are missing from suggest package also how
to pass to suggester.build method real index instead of mock words so it
can
that is because they are not in the suggest but in src test folder
2013/7/26 vonPuh fonPuhendorf vonpuhfonpuhend...@gmail.com
using lucene 4.4
2013/7/26 vonPuh fonPuhendorf vonpuhfonpuhend...@gmail.com
Hello i am trying to build the example but TermFreqPayload
and
27 matches
Mail list logo
