Hi Guillaume,
The problem is that the document id is indexed as a STRING field by
default, which is not matched by your sort type LONG.
To make it work, your options are:
* Use SortField.Type.STRING to match the field's type
* Index your id field as numeric field (which I suppose makes more
sense for your use case) in which case you can use sort type LONG:
@Id
@NumericField
private Long id;
Of course you also could keep the default String field and add a
second, numeric field for sorting.
Either way, you should mark the field to sort on with @SortableField
which will cause that field to get indexed as doc value field, making
sorting much faster (see [1] and [2] for the details):
@Id
@NumericField
@SortableField
private Long id;
As a side-effect, this will expose the mismatch between field and sort
type through an exception upon query time. We assumed this would also
be the case with index uninverting (which is used without
@SortableField) but apparently that's not happening. There is an issue
[3] for improving that. HSEARCH should detect the mismatch itself
before letting Lucene run the query.
Cheers,
--Gunnar
[1] see http://staging.in.relation.to/2015/09/14/sorting-in-hibernate-search-55/
[2] http://hibernate.org/search/documentation/migrate/5.5/#sorting-options
[3] https://hibernate.atlassian.net/browse/HSEARCH-1951
2015-09-23 23:18 GMT+02:00 Guillaume Smet <guillaume.s...@gmail.com>:
> And if I sort by creationDate desc, the sort is OK. So I really think
> there's something related to sorting on the id.
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
