When using Lucene's SortField.Type.INT to sort on a field which was not indexed as a NumericField, the resulting error message is confusing:
Wondering if we could improve on that, as this might be a migration issue: it seems previously - before Lucene 5 - this was more lenient (probably gave the wrong sort order, but it would not throw an exception).
A starting point it the test org.hibernate.search.test.sorting.SortingTest (about to be committed).
The opposite problem will result in something like:
I suspect in this case the field was indexed as NumericField, but it's being queried as SortField.Type.STRING
Apparently Lucene does not reliably raise an error if there is a mismatch between field type and requested sort type. E.g. see this case which returns wrongly sorted results for a field type of String and a requested sort type of Long.
The error you see I believe only pops up in some special cases (maybe involving an analzyed field?). Would be good to know the test which raises it. I saw it before but cannot remember how I produced it.
I had the problem the other day: it's quite easy to reproduce if you index a string which is analyzed in several tokens. If you sort on this field, you end up with this exception.
Thanks for this feedback, ! I suppose we should issue another warning when trying to sort on an analyzed field.
It's very common to sort on an analyzed field (typically, we put the text all lowercase, remove accents, remove special characters and so on).
The issue is more the tokenizer. We should check if the field is using a tokenizer different from the KeywordTokenizer.