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.
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. -- Jack Krupansky On Sun, Jan 11, 2015 at 12:08 PM, Michael Lackhoff <mich...@lackhoff.de> wrote: > Hi Ahmet, > > > You might find this useful : > > https://lucidworks.com/blog/whats-a-dismax/ > > I have a basic understanding but will do further reading... > > > Regarding your example : title:foo AND author:miller AND year:[2010 TO *] > > last two clauses better served as a filter query. > > > > http://wiki.apache.org/solr/CommonQueryParameters#fq > > You are right for a hand crafted query but I have to deal with arbitrary > complex user queries which are syntax-checked within the front end > application but not much more. I find it difficult to automatically > detect what part of the query can be moved to a filter query. > > > By the way it is possible to combine different query parsers in a single > query, but I believe your use-case does not need that. > > > https://cwiki.apache.org/confluence/display/solr/Local+Parameters+in+Queries > > Perhaps not, but how can I tackle my original problem then? Is there a > way to boost exact titles (or whatever is in pf for that matter) within > fielded queries, since that is what I have to deal with? The example > above was just that -- an example -- people can come up with all sorts > of complex/fielded queries but most of them contain a title (or part of > it) and I want to boost those that have an exact(ish) match. > > --Michael >
