Hibernate Search: Indexed Full Text Search of your Domain Model

Posted by Ryan Slobojan on Jun 18, 2007

Sections

Architecture & Design,

Development,

Operations & Infrastructure

Topics

Data Access ,

Search ,

Java

Tags

Hibernate

The second beta of the new Hibernate Search project was recently released. InfoQ spoke to Emmanuel Bernard, the project lead of Hibernate Search (and also of Hibernate Annotations and Hibernate EntityManager) to find out more. According to Emmanuel, the Hibernate Search project is aimed at users of Hibernate or the Java Persistence API (JPA) that want to make their Hibernate/JPA-managed objects accessible via indexed, full-text search. Some of the features of Hibernate Search include:

• 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?

1. Back to top

   Compass

   by Martin Gilday

   Is this targeting the same space as Opensymphony's Compass[1]? Both seem to ease integration with Lucene. Compass has excellent Hibernate support though its GPS system, as well as synchronisation with Spring transactions.
   
   [1]www.opensymphony.com/compass/

   Reply

2. Back to top

   Looks pretty good

   by Thomas Meeks

   Hibernate search is pretty neat and seems to have almost all of the bases covered. I'd agree that Sanjiv really is talking about a completely different use-case for lucene than what Hibernate would be targeting.
   
   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.

   Reply

3. Back to top

   Re: Compass

   by anjan bacchu

   Hi There,
   
   I'd be interested in the answer as well.
   
   BR,
   ~A

   Reply

4. Back to top

   Re: Looks pretty good

   by Emmanuel Bernard

   Hi Thomas,
   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.

   Reply

5. Back to top

   Re: Compass

   by Emmanuel Bernard

   Yes, this is the same space in the sense that it simplifies Lucene indexing and Lucene search for people using ORMs.
   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 :)

   Reply

6. Back to top

   compass

   by Uri Boness

   Actually, HSearch features are just a subset of the features offered by Compass. First, the generic and pluggable GPS mechanism in compass enables plugging in different content sources to be indexed/searched, hibernate/JPA is just one of many such plug-ins. This enables searching on more than just domain model, but also xml documents, file system, web sites, and databases that are not mapped to the domain. Further more, it provides transactional indexing support and as already mentioned integrates nicely with Spring transactions. It has much better index management than HSearch provides including configurable strategies for optimization and index partitioning. When comparing HSearch to Compass with ORM, they are both easy to use and configure and they are both very intuitive. Therefore, I would recommend using Compass for it's broader scope, maturity, and advance features.

   Reply

• Older >