Solr Query Parser Syntax

[MartinLichtblau]

I did some research on the topic and tried out what's possible and what is not.

• There are lots of Solr Query Parser plugins out there.
• Our friend @Makro is using the default parser lucene.
• Our friend @Makro could install one of the newer Query-Parser, which means one could choose which query parser to use for a search request. But since the use one very old Solr-version, they can't install the EDMS Parser but onyl the DisMax (See Note).
• It seems to be possible to dereference search parameters to other paramters.

So there are some options. I think the easiest one would be to stick with the ExtendedDisMax Parser and tell @Makro to install this one on there server in order use Saraphis.

[vyo]

We might introduce an additional endpoint in the style of of '/solr/{parser}/{query}', with '/solr/{query}' defaulting to '/solr/edsm/{query}'.

Or add an additional query param to the existing '/solr/{query}', such as /solr/{query}?parser={parser} or /solr/{query}?syntax={syntax}

In any case we might need an endpoint '/solr/parsers' to list the available parsers; although we might just as well rely on our documentation being awesome.

[MartinLichtblau]

Mhh, first option would mean a lot of overhead, I think. You would need to translate the query-in-some-syntax in som other. I'm prefering to stick to one for the time being. But being able to chosse the Query-Parser in Saraphis would be a nice feature of course.

[vyo]

Hmm, well, EDSM is a superset of DSM, so at least providing those two shouldn't be too much work. Specifying an appropriate parser is a single line in the code right now.

I guess we have to distinguish two use cases here:

• Using sarapis syntax (and specifying what it will be converted to, so that the backend may handle it properly)
• Using 'native' solr syntax (and specifying which flavour is being used)

Which result in slightly different workloads for us/clients:

• The first would be pretty easy to implement but would require passing additional config info to sarapis on startup, so that we know which syntax variants we may offer to clients. We might have to document respective parameters as only applicable to certain parsers. Plus, clients would be unable to use solr syntax.
• The second would be easy on the clients for they would be able to simply use native solr syntax without having to bother with our own - at the expense of us having explicitly support flavours ourselves, including all that whitelisting and sanitising business.

Note that I'm only talking about translating sarapis syntax into solr calls (which is rather easy, due to us using a clientside library) or passing on solr syntax of a given flavour (after some checks, naturally). Translating between solr flavours is none of our business, I'd say.

[MartinLichtblau]

True, translating between flavours is none of our business. These are two ways to deal with it, but I think it's still to much work for this problem. Reflecting what Sarapis purpose is I would suggest the following.

The easiest thing would be to specify no Query-Parser (flavour) at all in the query itself, which means the solr server would try to parse the incoming query with it's default QP. It would be no work for us and the user would need to be aware what the default QP is, or even which alternative QP could be used, to write appropriate client-side code.

What is the disadvantage in this approach?

1. Well, we would have to check if there are any parameter keywords that need to be put on a blacklist but the solr-proxy already got this funcitonality.
2. We couldn't use the admin/query board as it is now, with it's formular for the paramters. More?