I am trying to boost certain indices in my elastic search query. Right now, my query is looking like this.
var query = {
"query": {
"query_string": {
"fields": ["FirstName", "LastName"],
"query": "Hank Hill",
"default_operator": "AND"
}
}
};
var boosted_indices = {
"index_A" : 1.0,
"index_B" : 1.0,
"index_C" : 10.0
};
if (boosted_indices) {
query["indices_boost"] = boosted_indices;
}
// stringify and send query in an http.get request
I know that my query without boosting any indices works as I expect. However, I am still getting a lot of results from "index_A" in my query results, rather than the heavily boosted index_C. I know that there should be a similar number of matching results in A and C, so the issue must be that I am not boosting the query correctly.
Did I set up my query JSON incorrectly? On the tutorial I linked, it did not give much context.
One other thing I noticed.. the "_score" field for the returned documents... all of them are set to null. Might this have something to do with my documents not being boosted according to the index they came from?
I hope you are not using the sort parameter in query. This could be the reason that _score is null and you are not getting expected results.
Does this help?
Related
When I ran the query below on CosmosDB Explorer on Azure portal, several hundreds of RUs was consumed according to Query Stats.
select * from c where c.name = "john" and c._ts > 0
But after I added order by c._ts to the query above, only roughly 20 RUs was consumed.
According to the similar question, this behavior is expected.
(But I don't really understand why range filter is not enough to avoid looking at unnecessary indices)
So is it a good practice to use ORDER BY on the properties that are also used in range filter?
There is no guarantee that a ORDER BY query will use a range index although it normally does.
The best way to ensure you get a good index hit and thus lower RU consumption consistently is to use a composite index like below, of course adjusting your other properties as needed but you can see the _ts part in there as well.
This information can be found in the documentation here
{
"automatic":true,
"indexingMode":"Consistent",
"includedPaths":[
{
"path":"/*"
}
],
"excludedPaths":[],
"compositeIndexes":[
[
{
"path":"/foodGroup",
"order":"ascending"
},
{
"path":"/_ts",
"order":"ascending"
}
]
]
}
Why does this term match everything:
{result: $and[{$exists:true}, {$ne: 0}]}
{result:{$exists:true}, result:{$ne:0}} (this too as suggested)
The idea was to match fields, which have a key "result" and are where result is not equal zero. Why this does match a document, which only has a oid?
edit:
What works as expected is the following:
{ $and: [ { result:{$exists:true}}, {result:{$ne: 0}}]}
The question is still the same, why do those queries behaive like this?
try:
{result:{$exists:true}, result:{$ne:0}}
How can i conditionally test the output from an Execute SQL Query to make sure it returns some rows of data.
In my example below if the query returns no rows I don't want it to send an email, I want to do something else. What is the test?
Thanks for your time
I test, if it queries result is no rows, the query body will be like this:
{
"OutputParameters": {},
"ResultSets": {}
}
So you could add a Condition with #{body('Execute_a_SQL_query')['OutputParameters']} is equal to {}. If true, do the things you want. Yo could set this in the Code view mode.
The below is the test result, hope this is what you want.
This will work in Query SQL V2.
What is does is takes the ResultSet and converts to string. This prevent s a null error on the length function. As an empty result set is {}, the length is 2. So if the length is 2 then the the result is empty.
"expression": {
"and": [
{
"equals": [
"#length(string(body('Execute_a_SQL_query_(V2)')?['ResultSets']))",
2
]
}
]
}
I am using similar to this in an until condition which runs until the length is zero. I guess you could do the same?
#equals(length(body('Execute_a_SQL_query')?['value']), 0)
I would like to use suggest query and filter documents to be considered for suggestions by few fields. Is it even possible? I could not find anything about this in ravendb documentation link to doc
I have tried to add my filter conditions to queryable but no luck
using (IDocumentSession documentSession = _storeProvider.GetStore().OpenSession())
{
var queryable = documentSession.Query<SearchableProduct>("SearchableProducts");
var result = queryable
//I would like to filter by this field!
.Where(m => m.BrandNo == query.BrandNumber)
.Suggest(new SuggestionQuery
{
Term = query.SearchTerm,
Accuracy = 0.4f,
Field = nameof(SearchableProduct.ProductName),
MaxSuggestions = 10,
Distance = (StringDistanceTypes)2,
Popularity = true
});
return result.Suggestions;
}
Ravendb version: 3.0
You cannot use additional filters on suggestion query.
The way suggestion works, it evaluate a search term against the stored terms in the index, without considering other fields that may apply there.
You can use facets, to do filtering based on additional filters, and use the suggestion output as input to the facets, though.
I have three food type indices "Italian", "Spanish", "American".
When the user searches "Cheese", documents from "Italian" appear to come up at the top. Is it possible to "boost" the results if I were to give preference to say "Spanish"? (I should still get results for Italian, but based on some numeric boost value for index type "Spanish", the ordering of the documents returned in the results give preference to the "Spanish" index. Is this possible in user input lucene and/or ES query? If so, how?
Add a term query with a boost for either the _type field or the _index (or both).
Use a script_score as part of the function score query:
function_score: {
script_score: {
script: "doc['_type'].value == '<your _type>' ? _score * <boost_factor> : _score"
}
}
If querying several indices at once, it is possible to specify indices boost at the top level of object passed to Search API:
curl -XGET localhost:9200/italian,spanish,american/_search -d '
{
"query":{"term":{"food_type":"cheese"}},
"indices_boost" : {
"ilalian" : 1.4,
"spanish" : 1.3,
"american" : 1.1
}
}'
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-index-boost.html#search-request-index-boost
For query-time boosting, queries (ex. query string) generally have a boost attribute you can set. Alternatively, you can wrap queries in a custom boost factor. I would probably prefer the former, usually.