A question related to this. Is it ever meaningful to include norms for "int", 
"date", "long"... fieldTypes? Length normalization certainly doesn't make sense 
and what happens if you add an index-time boost to an int field? Would the 
boost be applied for queries like price:100 or price:[100 TO 200] ?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Solr Training - www.solrtraining.com

On 17. feb. 2012, at 09:29, Uwe Schindler (Commented) (JIRA) wrote:

> 
>    [ 
> https://issues.apache.org/jira/browse/LUCENE-3796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13210134#comment-13210134
>  ] 
> 
> Uwe Schindler commented on LUCENE-3796:
> ---------------------------------------
> 
> +1 to apply patch. This also effects NumericFields and any other norms-free 
> field.
> 
>> Disallow setBoost() on StringField, throw exception if boosts are set if 
>> norms are omitted
>> ------------------------------------------------------------------------------------------
>> 
>>                Key: LUCENE-3796
>>                URL: https://issues.apache.org/jira/browse/LUCENE-3796
>>            Project: Lucene - Java
>>         Issue Type: Bug
>>           Reporter: Robert Muir
>>           Priority: Blocker
>>            Fix For: 4.0
>> 
>>        Attachments: LUCENE-3796.patch
>> 
>> 
>> Occasionally users are confused why index-time boosts are not applied to 
>> their norms-omitted fields.
>> This is because we silently discard the boost: there is no reason for this!
>> The most absurd part: in 4.0 you can make a StringField and call setBoost 
>> and nothing complains... (more reasons to remove StringField totally in my 
>> opinion)
> 
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA 
> administrators: 
> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
> For more information on JIRA, see: http://www.atlassian.com/software/jira
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to