The context field can only be set at configuration-time for the
AnalyzingInfixSuggester (FYI: CONTEXTS_FIELD_NAME refers to the field in
Lucene index that is internally maintained by the suggester and does not
reflect any field in user's index). The context field can be specified and
fed into the s
Hi Lajos,
This can be due to the heavy query-time processing chain associated with
the TextField? You can also check out AnalyzingInfixLookupFactory, if the
suggestion entries are a bit long (this suggester will give matches, even
if the query matches a term in the middle of a suggestion entry.
I
Hi Lajos,
Can you elaborate on the "get the overflow when using a text field" part?
The new SuggestComponent should work just as well for DocumentDictionary.
Thanks
Areek
On Mon, Mar 17, 2014 at 6:05 PM, Lajos wrote:
> Hi Steve,
>
> I've posted previously about a nice Stackoverflow exception
== suggestion; spelling is correct, so why suggest it!). You can try
out the SuggestComponent (SOLR-5378), it does the right thing in this
situation.
On Mon, Feb 10, 2014 at 9:30 PM, Areek Zillur wrote:
> That should not be the case, Maybe the analysis-chain of 'text_spell' is
> doing some
> On Tue, Feb 11, 2014 at 1:57 PM, Areek Zillur wrote:
>
> > The FuzzyLookupFactory should accept all the options as that of as
> > AnalyzingLookupFactory (
> >
> >
> http://lucene.apache.org/solr/4_2_1/solr-core/org/apache/solr/spelling/suggest/fst/AnalyzingLookupF
The FuzzyLookupFactory should accept all the options as that of as
AnalyzingLookupFactory (
http://lucene.apache.org/solr/4_2_1/solr-core/org/apache/solr/spelling/suggest/fst/AnalyzingLookupFactory.html).
[FuzzySuggester is a direct subclass of the AnalyzingSuggester in lucene].
Have you tried the
This can be achieved using payloads in the suggester dictionary. The
suggester based on spellcheck component does not support payloads in
dictionary.
You can use the new suggester component (
https://issues.apache.org/jira/browse/SOLR-5378), which allows you to
highlight and return payloads.
The pa
Regarding LUCENE-5350, the context is the filter. i.e. the context is
prefixed with every entry (suggestion) that is in the context. So when
users lookup "foo" entry in context of "bar", the actual lookup is
bar(ctx_seperator)foo. This filters entries that match "foo" in another
context in the loo
Hey Hamish,
You might want to check this out LUCENE-5402 . I added support for
index-time pruning for suggesters that consumes from the index itself.
I plan to add this support to file-based suggesters as well.
In order to use this functionality from Solr, more changes are required. I
am planning
This error is misleading. It tries to load the suggester index from the
storeDir parameter even on the first run, when the index was not created to
begin with, and hence errors. (it will create the index itself when a build
command is issued).
I believe you will not see the error once the index is
>From the solrConfig provided it seems like you have only two named
spellcheckers defined (direct & wordbreak), but in your '/spell'
requestHandler you are setting three spellcheckers (direct, default &
wordbreak). As you do not have an unnamed spellchecker, there is no
spellchecker defined with th
11 matches
Mail list logo
