![]() ![]() The approaches Apache Solr has used in the past usually centered around terms considered in isolation. The idea is that based on partial input, suggestions for query terms typed so far are returned, think “type ahead”. How We Used to Make Suggestions:Īutosuggest has been around in various more or less sophisticated forms for a while. In fact, if you throw > 32K fields at these, they error out. The implication here, of course, is that by and large these are not suitable for large text fields. This is much different than term-based suggestions because the user sees coherent suggestions for query terms from documents in your index. The huge difference with these suggesters is that they return the whole field where the input is found!. At the end of this post are links to several backgrounders that are interesting to me at least. Along about Solr 4.7 or so support made its way into Solr so you could configure these in solrconfig.xml. There’s been a new suggester in town for a while, thanks to some incredible work by some of the Lucene committers. More on these suggester implementations later. One note, the first two above are from an FST-based suggester, and the second two are are from an AnalyzingInfix suggester. This blog is about how to configure the suggesters to get this kind of response, and also talk about some of the “gotchas” that exist. The Solr/Lucene suggester component can make this happen quickly enough to satisfy very demanding situations. In schema.How would you like to have your user type “energy”, and see suggestions like: If you want this fancy feature, you have to implement it yourself. This is very sad, since you need to get suggestions to implement TypeAhead search. Sadly again, Sunspot doesn't implement a suggester. With theses two tips and the documentation, you should be able to implement spellchecking without too many problems. A pull request was merged to fix this, but it never made its way to a release (at the time of writing, early 2018). This issue open in new window will show you the line to change : just monkey-patch Sunspot, replace at the end of line the number 2 by 0. The best solution is to just use collation all the time, but you have to tweak sunspot for that. This is annoying : your users might query one or more words, and you probably don't want to have to implement different solutions depending on the number of words. This way, you won't have backward corrections.In schema.xml, add this in the spellchecker component :Īnother thing to consider is that sunspot in its last release doesn't allow collation for 1 word. You get "Blu house", which yield no results.Ī way to fix this is to force Solr to only correct a word if it's not present enough in the index. "Blue" might get spellchecked to Blu and "House" is spellchecked to "House". You are trying to correct the query "Blue House". Which means if you have weird words in your database, you'll also have weird corrections.Įxample : You have the following words in your database => "Blu", "House", "Blue". Sunspot doesn't require an appearance threeshold when spellchecking your words. # Two points are important to consider there This means that sunspot will separate your words, correct them, and then put them back again together. In Solr's schema.xml, you can see that your queries are tokenized with StandardTokenizerFactory, which use whitespace as a token separator. However, if you need to implement queries of more than one word, you should use collation instead. We won't go into the detail of simple spellchecking there, the Sunspot documentation covers it very well. ![]() Let's look at three powerful implementations for a great FullText search experience : # Spellchecking Collation Sure you'll stop being invited to office parties because you'll be "the Solr guy" but it can totally be worth it. Solr is very powerful, mature and well-documented. You will try to find tutorials on the internet, but they are all deprecated because they pre-date ElasticSearch.īut that should'nt discourage you to use Solr. So you will get stuck and then your colleagues will make fun of you for not using ElasticSearch. There is a gem called Sunspot open in new window that is supposed to allow you to use Solr easily on Rails, but it's not been maintained correctly because everybody already migrated on ElasticSearch. Solr can be tricky to use but your main issue won't be Solr, it will be ElasticSearch. It's used by Netflix, Apple, Reddit, and most importantly, AOL. It's hipster.īut sometimes you have to use less-hipster stuff, like the search engine Solr. Solr allows you to do very powerful searches. # How to use Solr / Sunspot with Rails in 2018 like a peasant ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |