: Thanks Chris, but actually, it turns out that "query text" from elevate.xml : has to match the query (q=...). So in this case, elevation works only for : http://localhost:8080/solr/elevate?q=brain, but not for : http://localhost:8080/solr/elevate?q=indexingabstract:brain type of queries.
right ... query elevation by default is based on the raw query string. : but we have way more complicated queries which cannot be reduced just to : q=searchterm&... what would you want/exect QEC to do in that type of situation? how would it know what part of a complex query should/shouldn't be used for elevation? FWIW: ne thing you can do is configure a "queryFieldType" on in your QueryElevationComponent .. if specific, i will use the analyzer for that field type to process the raw query string before doing a lookup in the QEC data -- so for example: you could use it to lowercase the input, or strip out unwanted whitespace or punctuation. it night not help for really complicated queries, but it would let you easily deal with things like extra whitespace you want to ignore. I think it would also be fairly easy to make QEC support an "elevate.q" param similar to how there is a "spellcheck.q" param and a "hl.q" param to let the client specify an alternate, simplified, string for the feature to use -- feel free to open an issue for that and take a crack at a patch if you're interested. -Hoss
