I just kicked up Hibernate Search and have started kicking the tires and ran into a question. Currently Hibernate Search seems very centered around the Hibernate Query object, but this provides a bit of an issue for me in regards to paging. I have seen several implementations of paging and the one that I have found that works most efficiently and provides the most features uses the Hibernate Criteria object (specifically I am looking for the capability to return the number of results that meet the criteria through the use of a Projection). The method I found with the Query object uses the .list method on the results which essentially retrieves the entire query and basically eliminates any benefits that paging provides as the server now has all the query results in memory. Is there a way to get the count of records a fulltextquery would produce? I see there is the FullTextQuery.getResultSize() but this ignores additional Criteria placed on the FullTextQuery in it's count. Any guidance on this would be much appreciated, as with all things I am open to suggestions on how to better do this.

I suppose a simple search would have answered this

http://forum.hibernate.org/viewtopic.ph ... pagination

Is there any plan to implement this?

Hi, it is very hard to implement a well performing, database indipendent, all-use cases solution.

Discussion is welcome, this is more or less the problem:
the general idea is Lucene returns you a (potentially very long but pageable) list of primary keys; so you can get the page of PKs you asked for and load the matching entities. If you have to apply additional Criteria restrictions, you'll have to filter the objects with a query having a "pk in (1,7,22,45,48...)" and the "where" conditions you need (assuming your pk are simple types).
You could do that for the first pages, but you will potentially hit the database several times (until the number of desired objects are found, or all potential matches have being discarded), and to find out the exact number of matches you will have basically to scan your tables, hitting the DB several times as you can't give all PKs at once to the "id in (list)" to the DB without killing it.

So the conclusion is that you really want to avoid it; although for some specific cases this could be doable it would generally perform badly.
It is recommended instead to think carefully about the queries, and add enough tokens and markers to your index to be able to apply all restrictions needing fulltext directly on the index; that's why the Filters feature in Hibernate Search is very powerful: they help in solving this problem in a criteria-like approach.

I'd like to stress that DB-embedded fulltext extensions are having the same problem; they are also inefficient when having to mix the restrictions from the relational and fulltext worlds, so IMHO the only performing solution is think about the filters, map the object relations to your index, and keep them in sync: that's were Search kicks in to help you.

You'll find more insight in the book; and if you have some brilliant idea I'll be glad to try implementing it.