anything that could also work as a facet), then you are done already. But this makes maintenance hard! If you have structured data and you know that some fields in you documents are useful as auto-suggestion (e.g, names of authors, journal names. Generally you can do the same also with the new suggester, but you must take care of using a separate, deduplicated index and index the suggester phrases from there. The same like Google is doing - and this is what I would need (and the user who opened the issue). This suggester does not suggest documents, it just suggests terms/phrases you could enter into the search field and execute them. The old suggester was just "dictionary based" (a variant of the term dictionary that has payloads and some weights). One example of this is the search engine on Elastic's home page. If users click on those items, they are directly directed to the document. This type of suggester works fine if you index for suggestions is unique, e.g., the document title (that should be almost unique) and suggest those in the drop down. Basically this suggester just executes a query and returns TopDocs (not really Topdocs, because it uses another scoring, but basically it is the same).
The new suggester is document based, that is fine if you really want to suggest documents (and also want to filter deleted documents). Let me explain the 2 different types of Suggester "use cases":
ANOTHER WORD FOR SUGGESTER PATCH
Your patch on the Lucene issue already mentions it: If you have lots of duplicates, this slows down and the idea behind a suggester is broken (as its slow, possibly horrible slow). But nevertheless a Suggester that is document based is not always the best idea. Thanks for opening the Lucene issue! It looks good to me.
0 kommentar(er)
