Thanks for the clarification. The issue still remains that you need to distill all of the competing requirements into a single, concise, and consistent model, and whether that adequately aligns with existing Solr features remains problematic.
The general guidance is to stick with the existing Solr features and accept their limitations. In much the same way as the blog post that you cited details some rather stringent caveats. The alternative is to parse and pre-process the query yourself and generate a new query that more precisely meets your requirements. An intermediate solution is to detect some common use cases and handle them specially in your client. Such as the example you gave - you could extract the terms and generate separate bq parameters. -- Jack Krupansky On Sun, Jan 11, 2015 at 1:28 PM, Michael Lackhoff <mich...@lackhoff.de> wrote: > Am 11.01.2015 um 18:30 schrieb Jack Krupansky: > > > It's still not quite clear to me what your specific goal is. From your > > vague description it seems somewhat different from the blog post that you > > originally cited. So, let's try one more time... explain in plain English > > what use case you are trying to satisfy. > > I think it is the use case from the blog entry. I got the complaint that > users didn't find (at least not on the first result page) titles they > entered exactly -- and I wanted to fix this by boosting exact matches. > The example given to me was the title "Anatomie". So I tried it: > title:anatomie and got lots of hits all of which contained the word in > the title but among the first 10 hits there was none with the (exact) > title "Anatomie" the user was looking for. > As next step I did a web search, found the blog entry, implemented it, > was happy with the simple case but couldn't make it work with fielded > queries (which we have to support, see below). > > At the moment we even have only fielded queries since the Application > makes the default search field explicit -- which I could change but > would like to keep if possible. But even if I change this case I still > have to cope with fielded queries that are not just targeting the > default search field. > > > You mention fielded queries, but in my experience very few end-users > would > > know about let alone use them. So, either you are giving your end-users > > specific guidance for writing queries - in which case you can give them > > more specific guidance that achieves your goals, or if these fielded > > queries are in fact generated by the client or app layer code, then maybe > > you just need to put more intelligence into that query-generation code in > > the client. > > It is the old library search problem: most users don't use it but we > also have various kinds of experts amoung our users (few but important) > who really use all the bells and whistles. > > And I have to somehow satisfy both groups: those who only do a > one-word-search within the default search field and those with complex > fielded queries -- and both should find titles they enter exactly at the > top, even if combined with dozens of other criteria. > > And it doesn't really help to question the demand since the demand is > there and somewhat external. The point is how to best meet it. > > --Michael > >
