With the move to PointValues and away from trie based indexing of the terms index, for numerics, everything associated with the trie stuff seems to be labelled as "Legacy" and marked deprecated. Even FieldType.NumericType (now FieldType.LegacyNumericType) -- a simple enum of INT, LONG, FLOAT, DOUBLE. I wonder if we ought to reconsider doing this for FieldType.NumericType, as it articulates the type of numeric data; it need not be associated with just trie indexing of terms data; it could articulate how any numeric data is encoded, be it docValues or pointValues. This is useful metadata. It's not strictly required, true, but its useful in describing what goes in the field. This makes a FieldType instance fairly self-sufficient. Otherwise, say you have docValue numerics and/or pointValues, it's ambiguous how the data should be interpreted. This doesn't lead to a bug but would help debugging and allowing APIs to express field requirements simply by providing a FieldType instance for numeric data. It used to be self sufficient but now if we imagine the legacy stuff being removed, it's ambiguous. In addition, it would be useful metadata if it found it's way into FieldInfo. Then, say Luke, could help you know what's there and maybe search it.
Thoughts? ~ David -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
