We were aiming at creating a generic search framework for our application. Initially the plan was the use only Lucene/Hibernate search for all the search requirements and to have the framework abstract out the query building and searching. The aim was that the developers for different search use cases would simply pass the search criteria to the framework and would not need to know Lucene or Hibernate search.

We have two kinds of search requirements. In the case of full text search, we are clear that we need to use Lucene to benefit from features like fuzzy search and proximity search.

In the second case, we have the user selecting values for various fields from drop downs and searching for exact matches. In this case, we also need to show the number of search results using Ajax. I feel that Lucene/Hibernate search will give a high performance in this case because it can get the number of matching search results without a DB hit. However, some of our search queries involve several complex joins and subqueries. In such cases, I think it would be appropriate to use JPA QL itself since Lucene does not support joins and subqueries. In the forum also, the Hibernate search team has suggested a mixed strategy using JPA QL for traditional queries and Hibernate search for Lucene queries. But what I find confusing is the strategy to choose between JPA QL and Lucene in such cases? Maybe I can automate this strategy in the framework so that the search use case developer does not need to decide whether to use Lucene or just JPA QL?

Can you please guide me on the right path I need to take?

Thanks,
Seema