[
https://issues.apache.org/jira/browse/LUCENE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13028416#comment-13028416
]
Uwe Schindler commented on LUCENE-3065:
---------------------------------------
Mike: One thing about the bitmask and the 4 values. There is also an issue open
to extend NumericField by byte and short. Maybe we should reserve 3 bits
instead of 2 for the numeric field type - so 0x70 instead of 0x30 as mask? I
just want to reseve this one extra bit, so we dont need to do any dumb masks
and values later, if we extend.
About the index format change:
As described above, for Solr it's not a problem. New fields are always indexed
using NumericField. On the query side, when Document.getField is called, it
could simply check the return value with instanceof. If the getter returns not
a NumericField, Solr knows that it's binary and can decode manually. This would
safe backwards.
Else its no break at all if we support both stored field formats during
indexing somehow (in Lucene its string, returning a String Field or new binary
NumericField). The index format itsself does not change generally (no need to
bump version numbers, as we only use unused bits?)
> NumericField should be stored in binary format in index (matching Solr's
> format)
> --------------------------------------------------------------------------------
>
> Key: LUCENE-3065
> URL: https://issues.apache.org/jira/browse/LUCENE-3065
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Reporter: Michael McCandless
> Priority: Minor
> Fix For: 3.2, 4.0
>
> Attachments: LUCENE-3065.patch
>
>
> (Spinoff of LUCENE-3001)
> Today when writing stored fields we don't record that the field was a
> NumericField, and so at IndexReader time you get back an "ordinary" Field and
> your number has turned into a string. See
> https://issues.apache.org/jira/browse/LUCENE-1701?focusedCommentId=12721972&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12721972
> We have spare bits already in stored fields, so, we should use one to record
> that the field is numeric, and then encode the numeric field in Solr's
> more-compact binary format.
> A nice side-effect is we fix the long standing issue that you don't get a
> NumericField back when loading your document.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
