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? 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"?
-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
