Using Function Score query with field weighting without Nest

Elastic Stack Elasticsearch
1

Hi There,

I am trying to find an alternative to the 'WeightFunction' that Nest offers as I would rather stick with QueryDSL library for now.

What is the best way to construct the following WeightFunction list using QueryDSL? All the other syntax is the exact same for building the function score query except I see no equivalent to WeightFUnction where you can specify a filter along with the weight.

Below is the code I have which works using Nest but I need to replace WeightFunction with the QueryDsl equivalent.

Any guidance would be much appreciated.

var weightFunctionList = new List<WeightFunction>();

var matchQuery = new MatchQuery("field_name")
{
    Query = "field_value"
};

var weightFunction = new WeightFunction
{
    Weight = "field_weighting",
    Filter = matchQuery
};

weightFunctionList.Add(weightFunction);

var functionScoreQuery = new FunctionScoreQuery
{
    ScoreMode = FunctionScoreMode.Sum,
    Functions = weightFunctionList, // What other list can I add here??????
    Query = new ConstantScoreQuery()
    {
        Filter = boolQuery
    }
};
2

Hi @Matt_Shallow,

does the following work for you:

var weightFunctionList = new List<FunctionScore>();

var matchQuery = new MatchQuery("field_name")
{
	Query = "field_value"
};

var weightFunction = FunctionScore.WeightScore(2.0d);
weightFunction.Filter = matchQuery;

weightFunctionList.Add(weightFunction);

var functionScoreQuery = new FunctionScoreQuery
{
	ScoreMode = FunctionScoreMode.Sum,
	Functions = weightFunctionList,
	Query = new ConstantScoreQuery()
	{
		Filter = boolQuery
	}
};
1 Like
3

Hey @flobernd I think that is exactly what I need. I need to build some tests to make sure the weighting behaviour is as expected but I think this solves what I was looking for.

I must say the Nest way of building these objects is way more intuitive. That FunctionScore constructor behaviour had me quite confused as I was burning the midnight oil :sweat_smile:

4

Hi @Matt_Shallow,

yes, I agree that NEST is more polished in some places. Sadly, this is an unavoidable drawback of this kind of code generation (where the API surface directly is built from an API specification). We can make some custom tweaks here and there, but in some places it's not possible.

I will check, if I can improve the quality of the generated code for this particular case in the next major release.

1 Like