[ 
https://issues.apache.org/jira/browse/LUCENE-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13688631#comment-13688631
 ] 

Robert Muir commented on LUCENE-5069:
-------------------------------------

Sure but then you basically have 2 schemas :)

Alternatively we could argue numericrangequery is something that a QP should 
never generate anyway: instead maybe QP's should only worry about user intent 
and generate "RangeQuery", which rewrite()s to the correct type...

My point is we should just think these things thru without introducing 
additional schema-like things into lucene, since we already have enough of them 
(Analyzer configuration for example, is a form of schema, maintained by the 
user).
                
> Can/should we store NumericField's precisionStep in the index?
> --------------------------------------------------------------
>
>                 Key: LUCENE-5069
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5069
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Michael McCandless
>
> I was just helping a user (buzzkills) on IRC on why NumericRangeQuery was 
> failing to hit the expected docs ... and it was because s/he had indexed with 
> precStep=4 but searched with precStep=1.
> Then we wondered if it'd be possible to somehow catch this, e.g. we could 
> maybe store precStep in FieldInfo, and then fail at search time if you use a 
> "non-matching" precStep?
> I think you can index fine and then search on a multiple of that?  E.g., I 
> can index with precStep=2 but search with precStep=8?  But indexing with 
> precStep=4 and searching precStep=1 won't work ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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]

Reply via email to