I should add, it we keep FieldType.NumericType and use it as I suggest, it would either need a new enum value of "UNSPECIFIED" (think IPV6 or other custom uses) or null; I'd prefer to avoid the null. ~ David
On Thu, Mar 24, 2016 at 10:34 AM David Smiley <[email protected]> wrote: > 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 > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
