Searches fail with "special" chars

[ntarocco]

Try to do a search with "/". Invenio should escape the query string
https://stackoverflow.com/questions/40222694/escaping-special-characters-in-elasticsearch

[FlorianCassayre]

Actually, do we really want to escape user queries? Currently the user (patron or librarian) is given the ability to write advanced queries, such as document.title:"Little Prince". Moreover the server already returns HTTP 400 with the message "The syntax of the search query is invalid." when a query cannot be parsed; although the frontend leads to think that there was a server error. Given that information, the problem reduces itself to a frontend task and is likely a subset of #855.

[ntarocco]

Agree, we don't want to parse the query for sure! The task would be to investigate if it is easy to encode special chars only given the complete search query string.
If I have a literature with a title "Complex soft/hard ..." and I search for this book, the search will fail. But I want to search for a string with "/".

I think such search should work...

[FlorianCassayre]

I see, that's a very valid point. It would work if the user escapes the query string themselves, eg. Complex soft\/hard; but it's definitely not UX friendly. Malformed queries can also be crafted with unclosed quotes/brackets, and possibly other ways. Perhaps we could extend the ES DSL to allow fuzzy parsing (as it is the case for most modern search engines or even parsers in IDE). This could be achieved as a pre-processing step done by an invenio module.

[FlorianCassayre]

From the official documentation:

Because it returns an error for any invalid syntax, we don’t recommend using the query_string query for search boxes. [...] If you need the features of a query syntax, use the simple_query_string query, which is less strict.

I believe that's precisely what we need here.

Edit: Although very convenient the simple query DSL takes away some core features that we are currently using and which would not be easily replaceable, such as field:value (that is actually interpreted as value and checked against all fields). Therefore it is not a satisfactory solution and we should consider frontend error handling alternatives, ie.: inform the user that their query could not be parsed, link the query DSL document.