I have been trying to make use of the sorting functionality but after many tests I still can't get it to work. Basically, adding the setSort() method or omitting it has no effect and neither does specifying the 'reverse' parameter, when creating a new SortField.

One of my entities has a 'popularity_count' field:




which I want to use to sort by in my query:



Unfortunately, this has no effect on the result set, which is always the same.

What could I be doing wrong? Any help is appreciated. I searched the forum for similar questions but nothing I found them seemed to help.

I'm blind, sorry. Obviously the field name should be 'popularityCount' and not 'popularity_count' in the SortField constructor. I wonder why no exception is thrown in such a case...

Hi,
glad you sorted it out. It's very complex to validate for the Sort operation to be valid at runtime: that's the cost to pay for a "schemaless" structure: any sorting rule might be valid, especially since you can add any custom field on the fly.
But it's an interesting observation, I think I'll keep it in mind and see if there is anything we can do; maybe a diagnostic option. If you have any suggestion feel free to share it :)

For example I'm thinking we could scan the index in advance to identify valid fields; this would be a slow operation though so we'd need to only perform such a scan either once at boot or on user's explicit request, for example enabling an option on the DSL or via configuration.

Hey Sanne,

I'm not really too familiar with the internal structure of the project so it's hard to give my opinion. I just see that an exception is thrown if I use a wrong field in the onField() method of the QueryBuilder. That's why I was expecting the same for SortField. I was under the impression that it is easy to internally access the names of all the indexed fields.

Hi Pawel,
yes it's easy to enumerate all field names, but that's not enough.

The first problem is that enumerating fields is a slow operation, and you wouldn't want to do that on every query. And caching at boot time is also not really an option, since you can add new field names "on the fly" at any time, especially if you use custom field bridges or class bridges. That's what I mean when I refer to the drawbacks of a schema less model.

The other problem with such an enumeration, is that the fact a field exists isn't enough to make it a sortable field. It also needs to have a unique term for each document, and the only way to validate for that is either to trust our metadata (the indexing annotations) or to scan and validate each entry of the index, which would take weeks with a large index.

So we could implement a "quick check" for the field name to at least exist, but it would slow down performance a bit - so it should be a diagnostic option which I'd rather be able to turn off - and still it wouldn't be able to catch all cases.

It would be very interesting though, I'll think about it.

I'm very new to Hibernate Search so I don't know what percentage of users use the custom bridges. Currently, as you can see in my other thread, I'm struggling with the basic functionality of HS :) In my case, cacheing the field list at boot time would be sufficient but I understand what drawbacks you're talking about.

Have fun thinking about it and I'm looking forward to a possible solution :) In the meantime, I just need to pay more attention to what I write.

Exactly :)
But thanks for the feedback, it's very useful for us to better understand what the pain points are, especially from a new user. Keep it coming!