Currently I'm playing with Solr 4.6.1 and ES 1.0.2 which both use Lucene 4.6.1. The field content of "oa" has very low cardinality, actually only one of the values 0,1 or 2. Also, in Solr I have omitNorms=true because I don't want any index-time boost or anything else, and the precisionStep is zero. Belief me, it works like a charm for years now with Solr and all is 100 percent compliant to Lucene, the problem is Elasticsearch.
I just wanted to implement boost-query to my ES interface as it is in Solr for years. For example the boost should be if oa=1. I don't know why I should deal with huge function score query if I just want an extra boost during the query (selectable by the user). It seams like ES is not 100 Percent Lucene conform because it is not using omitNorms=true on numeric fields :-( The issue you mentioned is years ago and also fixed. Nevertheless the boosting problem of ES is somewhere in the QueryParsers which transforms the result of QueryBuilders to a Lucene query. Am Montag, 4. August 2014 18:57:11 UTC+2 schrieb Jörg Prante: > > Because integer fields have no norms, it is quite uncommon to use them for > boosting. More common is the use for interpreting integer values as input > for scoring algorithm with function score. > > Which Solr version is this? Solr did not follow the Lucene default in > previous versions regarding integer boosting > https://issues.apache.org/jira/browse/SOLR-3140 > > Jörg > > > > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/87c21bab-25b6-4ffd-9d9d-1f35dcf658e4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
