On 10/27/14 2:23 AM, Clemens Wyss DEV wrote:
Thx Mike,
at the moment I do not see/understand what the advantage of " feed a single suggester from
multiple fields" compared to "using copyfields to feed the suggester field" is?
The advantage is mainly in that you can apply different analysis and
different weights to different sources of suggestions.
Also, coming back to my main issue, how does your approach allow me to "filter the
documents to be taken into consideration for suggestions per suggestion request"?
Yes you're right, my plugin doesn't really offer a solution to your
problem, but there are some possibly helpful similarities: you will
probably want to write a custom UpdateRequestProcessor, and you will
want to feed the suggester with a custom Dictionary / InputIterator as I
have done in that example.
-Mike
-Clemens
-----Ursprüngliche Nachricht-----
Von: Michael Sokolov [mailto:msoko...@safaribooksonline.com]
Gesendet: Sonntag, 26. Oktober 2014 23:07
An: solr-user@lucene.apache.org
Betreff: Re: AW: AW: (auto)suggestions, but ony from a "filtered" set of
documents
This project (https://github.com/safarijv/ifpress-solr-plugin/) has some
examples of custom Solr UpdateRequestProcessors that feed a single suggester
from multiple fields, applying different weights to them, using complete values
from some and analyzing others into tokens.
The first thing I did was FieldMergingProcessor, which creates a new field,
kind of like copyfield, but allowing for some analysis/transformation to be
done just prior to copying the field values.
I think a better solution is MultiSuggesterProcessor and friends, which
multiplexes different input fields to a single suggester. It also manages NRT
updates to AnalyzingInfixSuggester
I haven't had a chance to up good docs or generalize very much, but if you have
questions feel free to get in touch.
-Mike
On 10/26/14 3:52 AM, Clemens Wyss DEV wrote:
Maybe you could use copyField to populate one field with the values
(fields) that you like to use for suggestions
We intended to do this in any case
take advantage on the EdgeNGramFilter placed in the new search field
Something like
http://lucidworks.com/blog/auto-suggest-from-popular-queries-using-edg
engrams/ but searching the copy-field (and the filter field(s))
instead of the separate index?
But then, wouldn't I be getting the complete content of the copyfield, instead of a
single word, as a "result"?
-----Ursprüngliche Nachricht-----
Von: Jorge Luis Betancourt González [mailto:jlbetanco...@uci.cu]
Gesendet: Samstag, 25. Oktober 2014 17:30
An: solr-user@lucene.apache.org
Betreff: Re: AW: (auto)suggestions, but ony from a "filtered" set of
documents
Maybe you could use copyField to populate one field with the values (fields)
that you like to use for suggestions, then you could search only on this field
and filter by any other field in your schema, and take advantage on the
EdgeNGramFilter placed in the new search field.
Regards,
----- Original Message -----
From: "Clemens Wyss DEV" <clemens...@mysign.ch>
To: solr-user@lucene.apache.org
Sent: Saturday, October 25, 2014 2:43:46 AM
Subject: AW: (auto)suggestions, but ony from a "filtered" set of
documents
Possibly making use of FilterAtomicReader?
http://lucene.apache.org/core/4_7_0/core/org/apache/lucene/index/Filte
rAtomicReader.html
-----Ursprüngliche Nachricht-----
Von: Clemens Wyss DEV [mailto:clemens...@mysign.ch]
Gesendet: Freitag, 24. Oktober 2014 18:31
An: solr-user@lucene.apache.org
Betreff: AW: (auto)suggestions, but ony from a "filtered" set of
documents
If possible I'd like to omit the sparate core. We have this approach in the
current Lucene-only-solution. The main drawback IMHO is, that whenever the main
index chnages you need to completely reindex the term-index.
Is it at all possible to write an own Suggester, which could do what I
want/need?
-----Ursprüngliche Nachricht-----
Von: Jorge Luis Betancourt Gonzalez [mailto:jlbetanco...@uci.cu]
Gesendet: Freitag, 26. September 2014 19:15
An: solr-user@lucene.apache.org
Betreff: Re: (auto)suggestions, but ony from a "filtered" set of
documents
Perhaps instead of the suggester component you could use the EdgeNGramFilter and provide
partial matches so you will me able to configure a custom request handler that will
"suggest" terms of phrases for you. I'm using this approach to provide queries
suggestions, of course I'm indexing the queries into a separated core.
Greetings,
On Sep 26, 2014, at 8:49 AM, Clemens Wyss DEV <clemens...@mysign.ch> wrote:
Either my intention is dumb (pls let me know ;)), or there is no answer to this
problem. If so, I will have to index my sources into separate cores.
But then the questions arise:
a) how do I get suggestions from more than one core? Multiple suggest-requests,
then merge?
b) how doe I get (ranked) results from more than one core?
In Lucene I was able to use a MultiIndexReader (one IndexReaders per
index)
-----Ursprüngliche Nachricht-----
Von: Clemens Wyss DEV [mailto:clemens...@mysign.ch]
Gesendet: Donnerstag, 25. September 2014 10:24
An: solr-user@lucene.apache.org
Betreff: (auto)suggestions, but ony from a "filtered" set of
documents
What I'd like to do is
http://localhost:8983/solr/solrpedia/suggest?q=atm&qf=source:<mysourc
e>
Through qf (or however the parameter shall be called) I'd like to restrict the
suggestions to documents which fit the given qf-query.
I need this filter if (as posted in a previous thread) I intend to
put "different kind of data" into one core/collection, cause
suggestion shall be restrictable to one or many source(s)
Concurso "Mi selfie por los 5". Detalles en
http://justiciaparaloscinco.wordpress.com
