What is the right way to query nested fields

Hi !

I am providing accessibility to search on ES using my own UI which uses query string.
Selecting query string is essential, beacuse the users might not be familier with advance quering in ES, And I would like to keep their queries as simple as possible.
In practice, I am just taking the user's query and send it to ES inside query string schema without changing the query itself.

The trouble is to query nested fields along other fields with query string.
From previous posts (Multi_match/query string with nested and "non-nested" fields - #6 by YeeP) and my own experience, I understood it is not possible.

My current solution is to parse every user's query from query string to dsl in the backend , which will must include considerating the field mapping (nested or not).

Is there a better way you can think of?
If not, is the parsing solution already exist?

Love for some help,
Eylon

Hey,

you are right, that the query_string query is not suitable. How about searching in your non-nested fields and your nested fields like this

user input: my favourite query terms

{
  "query" : {
    "bool" : {
      "should" : [
        { "nested" : { "path" : "...", "query" : { "query_string" : { "query" : "my favourite query terms", "default_field" : "nested.foo" } }}},
        { "query_string" : { "query" : "my favourite query terms", "default_field" : "non.nested.field"} }}
      ]
    }
  }
}

This is untested, but should help you to understand the principle I was referring to here...

--Alex

That is very similar to my solution of creating parser, which parse query string to dsl.
The main issue of this solutions is that for each user's query, I will need to parse his query and compare each field to the mapping, in order to find if it nested field or not.

This is heavy duty job and a lot more complex comparing to the current state.

Eylon

Hm, does it make sense to switch from a query string query to a multi match query so that the user cannot specify the fields and you do it for the user, or is this a feature?

if so, I'm afraid you need to go with your own parser then... I don't have any good idea to solve that.