> > If we do not need a new RC fort hat I can do it tomorrow! I am not yet > sure > > what to write: I tend to say: "Use NumericField, but with infinite > > precisionStep for low-cardinality fields - and you get the old TermEnum > > value list as before (with conversion through NumericUtils)". In > general, > > users should use NumericField for numbers, but use a appropinquate > precStep, > > so infinite if no faster RangeQueries are possible because of low > > cardinality. > > Okay, good point. That makes sense - how about an example of low card, > just for grounding? In the hundreds? Under 10,000? Only 10's?
The example of Phil is good: 24 for a hour fiel dis good. I would say, everything upto 100 is low cardinality. It does not hurt to use small precSteps, but you loose the possibility to enumerate the terms easily. The typical example of a drop down list filled by a list terms in the web interface is a typical example for low cardinality. E.g. credit card expiration,... These are no real numeric values (although "hour" is a number), they are used as list of preselected terms (and the list is intelligently filled by the index). I have a lot of these, but they are mostly country names, project names, and so on (or better said: facets). So: low cardinality lists. If you use numbers this way, you can handle them as simple text terms (and you will not use RangeQueries on them). > Also, do you mean to use Integer.Max_VALUE as infinite? Yes, sorry. > My personal opinion is that we can make javadoc changes for the final > without doing an RC, as long as no code/build/scipts at all is touched. > Not sure how others feel though. I just wanted to ask for confirmation. Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
