I use the edismax query parser to handle user queries against our Solr 4.10.3 server.
I configured the q.op parameter to AND and completely disabled the mm parameter in order to hit only 100% matches.
When users search for multiple terms in a single field everything works fine.
For example the query food:(beer cola pizza) returns only those documents that contains all of the terms beer, cola and pizza in the field food which is the expected behaviour.
But when users search in multiple fields Solr seems to forget about the q.op configuration and behaves as if the parameter was set to OR.
For example the query food:(beer cola pizza) AND color:(green yellow blue) returns all those documents that contains one of the terms beer, cola OR pizza in the field food and those that contains one of the terms green, yellow OR blue in the field color which isn't the expected behaviour.
A workaround is to explicitely prepare each term with the + operator just like this: food:(+beer +cola +pizza) AND color:(+green +yellow +blue).
But I need to add this operator in our java-webapplication which is kind of a 'hard code' feature. When users decide to configure the q.op operator back to OR the hard coded + would cause problems I think.
Is there a way to reach the expected search results by configuration?
Related
I'm trying to find a resource or explanation for how to determine how a field will display in the criteria or results dropdown of a saved search. For instance, in the results I would like to see the PO# field (fieldId:otherrefnum). But when looking through the drop down, I see neither of these as options. This has been a serious source of frustration for me with many other fields, I'd like to find a definitive way to avoid wasting time on this in the future.
Thank you!
There are a number of contributing factors to this.
The field names you see on forms may have been re-labeled by form customizations
Netsuite normalizes transaction searches to which leads to some (IMO) odd column name re-use.
A lot of old fields or fields tied to functionality (e.g. transaction status fields) don't follow the regular pattern of numeric id and text name.
The records browser helps quite a bit. You can search here and see that otherrefnum is named 'PO/Check Number' in the search editor. (An example of field name normalizing referred to above)
If you look at transaction you'll see it is just search filters and columns. If you compare to Sales Order you'll see something perhaps more familiar in terms of fields.
Even armed with the records browser experience is still needed. e.g.
A sales order has an items sublist and one of its fields is itemtype. In order to get that value in a search you need to select Item fields and then choose Type. A Sales Order's items.description column becomes the line level memo field in search results.
Hope this helps
I would like to sort the documents based on the position of the matching text and then alphabetically.
E.g I have follow 3 values.
PATRICK STREET WEST
MOUNT ST PATRICK ROAD
PATTI MCCULLOCH WAY
I am search with Pat* and I want the results should be sort by the position of the matching text and then alphabetically.
E.g Required result
PATRICK STREET WEST
PATTI MCCULLOCH WAY
MOUNT ST PATRICK ROAD
but I am getting the result in the below order.
PATRICK STREET WEST
MOUNT ST PATRICK ROAD
PATTI MCCULLOCH WAY
This is a bit of a tricky requirement. Let's break this down into the two distinct asks:
Sort results based on the position of the text - there's no query syntax that would allow you to do this but there are some ways to get at this requirement. One option to allow you to boost documents that start with Pat would be to create a second field with the same text that uses a custom analyzer with a keyword_v2 tokenizer and lowercase token filter. That new field would only match if the string of text started with the letters Pat. You could then use scoring profiles or term boosting to weight matches in that field more to bring those results that matched at the beginning to the top.
Sort alphabetically - I'd recommend sorting by search score and then by the text like this: $orderby=search.score() desc,TextField desc. If you follow my recommendations from #1, items where they matched in the beginning of the string should have higher scores than other items and then can be sorted alphabetically within that set. Then all items where the match wasn't in the beginning will come after and will also be sorted alphabetically.
That should at least get you fairly close to the requirement! You could always do a bit of extra sorting on the client side if needed too.
I'm currently doing a prefix search with Azure Cognitive Search like so:
docs?api-version=2019-05-06&search=Do*
Suppose that my index contains Dog, Big Dog, and Small Dog. The result set seems to be sorted alphabetically by default and looks like:
Big Dog
Dog
Small Dog
How can I change my query string so that the closest exact match appears first and the rest is sorted alphabetically? Here's the output I want:
Dog
Big Dog
Small Dog
So, if the user types D, Do, or Dog, I want to show Dog first to help them short-circuit typing.
The results are ordered according to a score. This, is the result of TFxIDF formula. In other words, the results are displayed according to which term is more relevant according to your documents.
Saying that, I believe you must use NGram in order to get the most relevant term.
more info:
https://azure.microsoft.com/en-us/blog/custom-analyzers-in-azure-search/
Can you share what your exact document looks like? As Thiago mentioned Azure Cognitive Search returns a relevance score which shows the relative relevance of the entire document corresponding to the input query.
If your documents have only 1 matching field with the exact text you shared, it should return "Dog" with the highest score as it's more relevant to the query.
I want to filter an index by an exact value of an attribute. I wonder what possibilities Algolia offers for that.
Querying an index always results in a search for substrings, that means a search term abc will always match any object which attribute values contain abc. What I want to achieve is a search for abc that finds only abc as a value of an attribute (in this case I have specific attributes to search in).
One possibility I came up with was tagging, which doesn't seem to be the best way to think of.
Edit
I think I could also use facet filters. I thought about the different pros and cons and can't come up with arguments that places either one position above the other.
You're right with your edit that facet filters would be the way to go on this one. You'll get the exact match you're looking for and won't have to create a new attribute of _tags to use the tag filter.
I am not sure if this can be done with solr. But this is what I am doing for an online store search functionality. The main search box is a dismax parser for multiple fields :
qf: description^1.0 color^1.0 name^1.0 size^1.0
Equal weight across multiple fields for now. Further I create a facet on some of these fields
ex: color, size. The client has a request that when they search using a particular keyword and it matches any of the faceted fields the filter appear selected in the front end. So if the user searches for 'red' The color facet for red should appear selected.
Since solr is searching across multiple fields I don't think this is possible or is it?
It is not about Solr. First, This requirement is flawed at user experience level. Traditionally facets (also known as guided navigators) are used to filter search results. Just having "red" across multiple fields does not mean all the products appeared are colr "red" .
When you have "red" selected in Co filter you are visually telling user that all products in search results are "red". If that is not the case do not do it.
It that is the case, then ideal situation is, when the user enters "red" , you should first check user input against colr facets (preferably against cacheed list) and then add that color as filter to query as fq=colr:red parameter so that it is "true" filter and is part of your search query. This can be done against all known displayed facets (colr,size etc.) very quickly and activate them automatically if there is a match. Used right, that would actually make a cool feature.