Hibernate Search: Indexed Full Text Search of your Domain Model
- Lucene integation - Lucene has a proven track record as a powerful and efficient search engine
- Automatic insertion and updating of data - When an object is added or updated by Hibernate, the search index is also transparently updated
- Support for many complex kinds of search - You can perform wildcard searches, multi-word text searches, approximation/synonym searches, or ordering of search results by relevance in a very fast manner
- Search clustering - Hibernate Search has some built-in clustering solutions, including a JMS-based, asynchronous querying/indexing system
- Direct Lucene API fallback - If you need to do something particularly complicated, you can use the Lucene API directly to form your queries
- Automatic Lucene management - Hibernate Search takes care of managing and optimizing Lucene's index, and using the Lucene API in an efficient manner
The major goals for the project include:
- Ease of use - Like Hibernate's ORM, Hibernate Search does the job for 90% of your cases and lets you focus on the the remaining, more difficult portions
- Consistency with the existing Hibernate/JPA programming model - A natural integration with this programming model "has been a goal from day one"
Emmanuel gave us a few concrete examples of these goals in practice, including:
- An HQL query can be turned into a search query by changing the way an object is built, "a few lines of code usually" - everything else (query execution, result format) is the same
- There is no bootstrapping process, because Hibernate Search transparently leverages the existing Hibernate/JPA infrastructure
- The minimal configuration requires that two properties be set in either persistence.xml or in hibernate.cfg.xml
On the final release schedule, Emmanuel indicated that Query and Index optimization are two areas where he sees some more work being done before 3.0 is released, and he concluded with:
The Hibernate Search core code is fairly stable actually. The main reason why it's marked as beta is because we are still unsure of some of the extension APIs, Hibernate Search core is fairly flexible and you can plug a bunch of custom strategies. While they have been fairly stable so far, we would like to have a feature complete product to be sure the API won't evolve and break.
You know the usual song. An open source project is released when it is done. All I can say is the the summer is long and I haven't planned much vacations :)
An interesting debate discussing the pros and cons of the Hibernate Search strategy has also begun, with Sanjiv Jivan describing good and bad points that he sees with Hibernate Search, and Emmanuel Bernard responding to Sanjiv's concerns. What is your viewpoint on Hibernate Search?
Looks pretty good
That said, in going over the documents, it looks like HSearch cannot embed objects bidirectionally (at least according to the notes at the bottom of 3.1.2).
To use the same example in the docs (Place object with a one-to-many relationship to an Address object) -- there are cases in which I need to embed the Address into the Place *and* all of the Places an Address references into the Address.
I am, of course, no HSearch expert, so I'd love to hear that I missed that functionality somewhere.
Re: Looks pretty good
The bidirectionality is supported except a specific case: when only a collection is updated (not it's owning entity - in your example, a new place added to an address), the update event is not propagated (HSEARCH-56). People use the collection support already, knowing the limitation and the workaround. I need to work with Steve to incorporate the fix.
However the user experience approach is different as Ryan described: for people familiar with JBoss Seam, this is the same approach: a unified programmatic model (expect some integrations with Seam soon - I hope).
Best thing is to check the docs to figure it out.
BTW: Hibernate Search is no longer beta2, but beta3 :)
John Altidor, Yannis Smaragdakis Mar 30, 2015