This project is read-only.
1
Vote

Implemented PrecisionStep of NumericField is making searching nearly impossible

description

Either you make Lucene.Net.Odm.Helpers.MappingHelper.DefaultPrecisionStep public, or, and this would be way better (!!), let the PrecisionStep inject within the .AsNumeric()-method.

Flucene is using 64 (and not Lucene.Net.Util.NumericUtils.PRECISION_STEP_DEFAULT), which makes searching with a NumericRangeQuery-instance nearly impossible, because you do not know the concrete PrecisionStep - so it won't work...

Also:
You might consider the docs
Good values for precisionStep are depending on usage and data type:
  • The default for all data types is 4, which is used, when no precisionStep is given.
  • Ideal value in most cases for 64 bit data types (long, double) is 6 or 8.
  • Ideal value in most cases for 32 bit data types (int, float) is 4.
  • For low cardinality fields larger precision steps are good. If the cardinality is < 100, it is fair to use Integer.MAX_VALUE (see below).
  • Steps =64 for long/double and =32 for int/float produces one token per value in the index and querying is as slow as a conventional TermRangeQuery. But it can be used to produce fields, that are solely used for sorting (in this case simply use Integer.MAX_VALUE as precisionStep). Using NumericFields for sorting is ideal, because building the field cache is much faster than with text-only numbers. These fields have one term per value and therefore also work with term enumeration for building distinct lists (e.g. facets / preselected values to search for). Sorting is also possible with range query optimized fields using one of the above precisionSteps.

comments

dittodhole wrote May 16, 2013 at 3:30 PM

Hello!

Just fixed this issue with my pull request