It took us a long time to have the concept of "NumericField" fully exposed to Hibernate Search users, as a primary concept people are getting familiar with.
Which means of course that the Lucene team is going to get rid of them in the near future: [1]. NumericField(s) will live for a bit longer in a "backwards-codec" package, and to be fair the migration makes sense for Lucene as the new alternative structure is delivering much better performance across the board (less indexing time, better query times, less index space, ...). So what I'm wondering now is if it was a mistake to expose this. For sure since we're up to redesign the API soon we should keep this in mind, but also while we traditionally made "the best choice" automatically out of the box about how to translate certain types to the index world, we always allowed for power users to override our defaults. So what's the correct level of abstraction here? We want to allow power users to use specifics, but not keep breaking APIs. Or should we just accept that such level of details will keep changing? Ideas very welcome.. Thanks, Sanne 1 - https://issues.apache.org/jira/browse/LUCENE-6917 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
