Open homersimpsons opened 5 years ago
An excellent catch @homersimpsons. Will write a test for those cases and will double check if repositioning processArray()
fix the issue.
@saimaz Thank you.
Moving the processArray()
won't give the expected result, for example if one use 'boost' => 2.0
he expect it to be at the FieldLevel (i.e. 'field' => ['boost' => 2.0, ...]
) so this processArray()
should stay here...
I guess the best is to get 2 array of parameters:
FieldParameters
: That will be used at FieldLevel, and remains in constructorQueryParameters
: That would be used at QueryLevel (and get accessed only via accessors ? or last param in constructor ?)Then in the process of building the array this will be generated
[
$this->field => $this->fieldParameters,
...$this->queryParameters // (via array_merge / processArray())
]
So the resulting Query would be
[
$query->getType() => [
'field' => [FieldParameters],
...QueryParameters
]
]
For some query like the
RangeQuery
or theTermQuery
an extra parameter like_name
(used for Named Queries) won't be at the top level.Example:
This is due to the use of parameters as query parameters and not extra ones https://github.com/ongr-io/ElasticsearchDSL/blob/197eeddacccf2195bd7a9e0572ef24bb50a700c8/src/Query/TermLevel/RangeQuery.php#L72
It's the same for
TermQuery
https://github.com/ongr-io/ElasticsearchDSL/blob/197eeddacccf2195bd7a9e0572ef24bb50a700c8/src/Query/TermLevel/TermQuery.php#L70 I think here theprocessArray()
should be called after...This works with a Terms query: