: > defType=edismax q=sysadmin name:Mike qf=title text last_name : > first_name : : Aside: I'm curious about the use of "qf", here. Since I didn't want my : users to have to specify any particular field to search, I created an : "all" field and dumped everything into it. It seems like it would be : better to change that so that I don't have an "all" field at all and ... : Does that sound like a better approach than packing-together an "all" : field during indexing?
well -- you may have other reasons why an "all" field is useful, but yeah -- when using dismax/edismax the "qf" param is really designed to let you search across many diff fields, and to associate query time weights with those fields. see the docs i linked to earlier, but there's also a blog post on the scoring implications i wrote a lifetime ago... https://lucidworks.com/2010/05/23/whats-a-dismax/ : > ...the examples above all show the request params, so "f.last.qf" : > is a param name, "last_name" is the corrisponding param value. : : Awesome. I didn't realize that "f.alias.qf" was the name of the actual : parameter to send. I was staring at the Solr Dashboard's selection of : edismax parameters and not seeing anything that seemed correct. That's : because it's a new parameter! Makes sense, now. that syntax is an example of a "per field override" where in this case the "field" you are overriding doesn't *have* to be a "real" field in the index -- it can be an alias and for that alias (when used by your users) you are defining the qf to use. it could in fact be a "real" field name, where you override what gets searched "I'm not going to let them search directly against just the last_name, when they try i'm going to *actually* search against last_name and full_name" etc...) -Hoss http://www.lucidworks.com/
