Again we dont care except that its bytes. FieldInfo already records the same thing we recorded for legacy shit:
the length in bytes. That is all legacy numerics ever knew before (simply from the length of the term), if it was 32 or 64 bits. It could not differentiate integer from float, you could never do that. nothing was removed, there is no feature to keep here. On Thu, Mar 24, 2016 at 10:42 AM, David Smiley <[email protected]> wrote: > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
