You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (JIRA)" <ji...@apache.org> on 2013/06/19 21:31:21 UTC
[jira] [Comment Edited] (LUCENE-5069) Can/should we store
NumericField's precisionStep in the index?
[ https://issues.apache.org/jira/browse/LUCENE-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13688346#comment-13688346 ]
Uwe Schindler edited comment on LUCENE-5069 at 6/19/13 7:30 PM:
----------------------------------------------------------------
I think we can do this. I had the same in mind, but lots of people were against for schema reasons (you know, no schema info in index). If we save precision step we should also save type like we do for stored fields.
The search works with multiple of original precision step is correct, btw
While indexing, adding a new item with different step should also fail. The check on searching would be done in the TermsEnum initialization of mtq's getTermsEnum().
was (Author: thetaphi):
I think we can do this. I had the same in mind, but lots of people were against for schema reasons (you know, no schema info in index). If we save precision step we should also save type like we do for stored fields.
The search works with multiple of original precision step is correct, btw
While indexing, adding a new item with different step should also fail. The check on indexing show would be done in the TermsEnum initialization of mtq's getTermsEnum().
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org