Can't use _ or * in EuiSearchBar

[jen-huang]

Entering search terms containing _ or * errors out:

Use case:
In Management > Saved Objects, users can use the search bar to filter table of saved objects by name. Saved objects include index patterns, which often have the above characters in their name.

[uboness]

we'll need to add * and _ to https://github.com/elastic/eui/blob/master/src/components/search_bar/query/default_syntax.js#L161

that said, adding support for * won't necessarily mean * will be treated as a wildcard - this highly depends on the search services that will eventually handle the query, which is beyond the scope of this component (all this component does is provide you with the AST the user entered).

[uboness]

btw, we might want to add the supported term characters to the schema... such that it'll be configurable

[chandlerprall]

I don't believe adding * and _ is the real fix. There's a few things going on:

1. what characters are valid in a term (current issue: * and _ are missing)
2. what characters can begin an unquoted term
3. when quoted, what characters can the term contain

Related, "text:" will throw an error as : is parsed outside the context of the quoted term.

Is there decent/full documentation of what/how syntax should be parsed? The Kibana docs says Kibana's query language is based on Lucene's query, but doesn't provide a detailed description.

[uboness]

I don't believe adding * and _ is the real fix. There's a few things going on:

what characters are valid in a term (current issue: * and _ are missing)

it's a bit of a contradiction. The question you're asking is the right question, and if the answer is that _ should be valid in a term, then adding it as a valid char is the real fix for this. Same goes for *, except here we need to ask about the intention, and as I mentioned above, if the intention is to add it hoping to have wildcard support (which I think is the expected behaviour) then I don't agree it needs to be added as a valid character (unless we're planning to support wildcard support, which I don't think we should even attempt that).

what characters can begin an unquoted term
when quoted, what characters can the term contain

These are not the right questions to ask. The question should be "what characters are valid as within terms and/or within field values". Once you have answer to this, then you need to make sure the grammar supports it. Quoting does't change the validity of the terms/values it contains.

Related, "text:" will throw an error as : is parsed outside the context of the quoted term.

sounds like a bug

Is there decent/full documentation of what/how syntax should be parsed? The Kibana docs says Kibana's query language is based on Lucene's query, but doesn't provide a detailed description.

this is not KQL nor Lucene... EUI search bar for now has it's own grammar and AST (the plan was at some point to port it to KQL, but there's a lot that needs to be done there... e.g. KQL is a Kibana thing, EUI is not)

the syntax is here: https://github.com/elastic/eui/blob/master/src/components/search_bar/query/default_syntax.js

the AST is here: https://github.com/elastic/eui/blob/master/src/components/search_bar/query/ast.js

[uboness]

to clarify this:

btw, we might want to add the supported term characters to the schema... such that it'll be configurable

The reason I mentioned that as an option to consider is that in different contexts and use cases, one may have different constraints on valid characters...

btw... as part of the discussions of supporting KQL, one of the things we can do is creating a higher level interface QueryEngine abstraction that the search bar would work with (instead of tying it to a specific grammar/AST)... this way the search bar can still live in EUI, and kibana can write a KQLQueryEngine to hook into it. (we can still have an EUIQueryEngine that can serve as a default implementation).

The main thing to consider here... is that the intention here was on one hand to keep the query language very simple... as basic as possible, and at the same time, make it easy to make sense of the AST such that the filter controls associated with it can resolve their state. (For example, the current language only supports ANDing on the top level and ORing on the second level... that's it... one cannot nest addition boolean clauses deeper than that... intentionally)

[chandlerprall]

Agreed on all counts; adding the two characters fixes the immediate issue, and you raised the question behind my statements - what characters are valid as within terms and/or within field values

Was there ever a set expectation?

[uboness]

Was there ever a set expectation?

not really... I came up with the initial set of characters based on my needs at the time... tried to keep it a small set to begin with, knowing we can always expand it as we find the need.