Solr queries also support boolean operators like in SQL: tQuery("brand1 AND (Washing OR Refrigerator)") Īll boolean operators must be in all caps those backed by the query parser are AND, OR, NOT, + and –. We can use wildcard characters * and ? in our query: tQuery("*rand?") We want to search any word containing “rand”, that starts with any number of characters and ends with only one character.
Note that simple searches are not case sensitive. The search query above will look for any documents that contain the complete word “brand1” in any of its indexed fields. The number of returned records will be 10, indexed from zero when start and rows are not specified. SolrJ will internally use the main query parameter q in its request to the server. List items = response.getBeans(Item.class) I will need to look into that a bit more.QueryResponse response = solrClient.query(query) Or you mean a yml config from a custom module? For the current project the client is ok with suggestions based on the titlesīut the field we want to use for the suggester should be multivalue with short phrasesīTW in 2.0 you can declare your own Solr fields that have their own suggester by a yml configĪnd they pop up in the Search API Index config as field type. Yep, so using that for the suggester is an issue. In 2.0 we'll have the chance to get rid of it / replace it BTW the spell field is a very bad thing at all! We already have some protection for this but obviously not enough. It is a separate issue to solve, but that will come up for sure That is something people would definitely run in to.
Solr php suggester Patch#
So you will work on a patch that extends getAutocompleteSuggestions to leverage the suggester_phrase switch? It was quite a large site, so the spell field was to big to store for AnalyzingInfixLookupġ. I ran into this issue yesterday "Document contains at least one immense term in field="exacttext"" I will start with some basics like implementing the actual checkbox and doing a actual suggestor based autocomplete query Search_api/index:XYZ search_api_solr/site_hash:XYZ drupal/langcode:XYZīut if you are able to add custom context options to documents and alter the query to limit to a context the possibilities are endless Looks like a great thing, I think the hooks to add extra contexts to documents are already there.Īnd a hook to alter the query to provide a custom custom based on a view or whatever is also there. The cfg paramater should limit the suggestions based on values in sm_context_tags. That's the exact reason why I started working on this, to filter the autocomplete results. In opposite to the Terms and the Spellcheck component, the Suggester could be filtered by boolean queries. Īs an alternative approach, the autocomplete should leverage the Suggester component. The problem with the current implementation is that the Terms component and the Spellcheck component are only suitable if you run a single index on a core. Īs proven by the tests on travis nothing else (especially the behavior of the autocomplete) did change so far.
Solr php suggester code#
The last patch also cleaned up the code to not hijack the select query anymore but uses a new query type "AutocompleteQuery" (possible since Solarium 4.0). WIth the last patch it now includes the Terms component, the Spellcheck component and (new) the Suggester Component. We already had an "autocomplete" handler in our Solr configs.
I worked on it for 6 weeks now to prepare solarium for it and simply committed what I got on my machine I'' try to have a patch ready for review tonight/tomorrow. The part below are relevant to implementing the suggester based autocomplete. Had an interesting talk with mkalkbrenner on Slack today.
0 kommentar(er)
