I understand what you ask for, but as you pointed out it needs to deal with firstResult / maxResult => this is problematic and cannot be done efficiently passes a certain amount of returned results but #1

The reason I am reluctant is:

• it is quite inefficient when lots of results are invloved

• it can be done manually by the user

But I will think about it more.

Hmm, I think I'm missing something. The sequence as far as I can tell is:
1. Do a Lucene search, return entity ID's
2. Use Hibernate to construct a SQL Query that uses the ID's from step #1 to get the entities themselves
3. Return entities sorted by #1

What I'm asking for, is for #3 to honor the sort of the results returned in #2, since I can already influence the sort clause that is constructed.

I think you are sliding to a different subject which is mixing Lucene and SQL queries. As you mentioned, this is not a generically fixable problem.

Back to the original subject, if you manage to get a small amount of elements from Lucene, then I imagine sorting the data in memory (using Comparable) will be quite trivial and fast. If you have a huge amount of data returned from the Lucene query, you're back to the problem I described initially. That is the reason I still need to be convinced before putting a double edge sword into people's hands

Sure. I'm not saying this should be an either/or. I think there are going to be situations where it's more practical and efficient to do this in Lucene, and others where it's the reverse. Obviously a million element search result wouldn't be practical to do in db. I think it's should be a judgment call by the developer as to which path to take.

Consider the opposite problem. You have a fairly complex query, sort, filter problem that requires many fields and calculations. You need to do a full text search (or filter) on only one of those fields. The query is not expected to return many elements. In the current situation you would need to replicate all the fields that participate in that query into a Lucene index. This fairly quickly turns your Lucene indexes into an almost full replica of your database.

So let's say you have one million matching elements, Hibernate Search will have to read one million id, and do a firstResult / maxResult in database in one giant query requesting all the ids if we are in an optimistic situation.
Pessimistic situation (some EAGER collection loading is on the work), we would have to sort 1 million objects in memory.

I don't see this as a practical solution. But let's try to push the discussion further.