Over a million developers have joined DZone.

Adding the Power of Search to Your Hibernate App the Easy Way

· Performance Zone

See Gartner’s latest research on the application performance monitoring landscape and how APM suites are becoming more and more critical to the business, brought to you in partnership with AppDynamics.

I’m currently working on a software project with a data layer that is built using Hibernate – an Object-Relational Mapping (ORM) framework that takes a lot of the tedious work out of tying a Java-based application to a relational database. We recently found that the system needed to expose a full-text search mechanism for a subset of the data being stored in its backend Oracle database. Our first instinct was to deploy a standalone instance of the Solr search platform, which is built on top of the very popular and mature Lucene search engine library. We’d then have our core application call out to the Solr engine remotely and have Solr return search results in JSON format. If you’re an experienced Java developer, I have no doubt you’ve at least heard of all these technologies.

I’ve never personally had a need to implement full-text search. However, I was familiar with basic full-text search concepts and I did know that Solr was one of the more popular search options. I was casually chatting with one of my colleagues – Eddie – about his project and he mentioned that his team had selected Hibernate Search as their search solution. For whatever reason (perhaps it’s the seemingly gazillions of technologies out there that overpower me with their sheer numbers), I hadn’t heard of, or at least hadn’t paid any attention to, this technology. However, I was intrigued, since, like Eddie’s project, our application already leveraged Hibernate for data storage and retrieval. So, I did some research and decided that leveraging the Hibernate Search library was a better option in our case than a standalone Solr search engine.

If your application already uses Hibernate to persist data and it’s unlikely that other external applications will need to update or perform a full-text search against your data (without going through your application’s Hibernate layer, that is), there can be some major advantages to using Hibernate Search versus a standalone search engine:


Using Hibernate Search allows you to delegate the synchronization of the search indexes and relational database to Hibernate itself. You do not need to write any code to update Lucene indexes – when Hibernate Core and Hibernate Search are used together, you pretty much just apply Hibernate Search annotations to the fields in the POJO classes you want to be searchable – no kidding, that’s pretty much all you do to get them indexed in Lucene! Hibernate will monitor “indexed” entities – if an entity is added, updated or deleted via Hibernate, the index is transparently updated as well.


The Hibernate Search API is going to be very comfortable for any developer who has experience using the Hibernate API. The learning curve will be minimal. In fact, to enable fairly basic full-text searches against existing Hibernate-managed entities is trivial.

You eliminate the need to manage another server and another technology set. I always try to remind myself of this principle: every technology or resource I add is another dependency for my project. And, dependencies always represent additional risk – and, often, additional learning curves and work.

Having said that, Hibernate Search is not a replacement for standalone search engine approaches in all cases. For example, I don’t think it would be appropriate for scenarios in which some of the data that needs to be searchable resides in multiple data stores – in other words, you’re building a more generalized corporate search solution with data sourced from multiple repositories.

Persistence of the data to be searched is not managed by Hibernate. If Hibernate isn’t already managing your data persistence, you lose the (in my opinion) primary benefit, which is allowing Hibernate to keep the Lucene indexes up-to-date as the data in the database changes.

The obvious poster child for Hibernate Search is the scenario in which you’re already using Hibernate to persist your data and you’re simply looking for a simple, straightforward way to expose the data managed by your application via full-text search. That case seems like a no-brainer to me. It really is easy to search-enable existing Hibernate applications using Hibernate Search.

I plan to post an example or two – some “getting started” posts – very soon and share a couple of the “gotchas” I encountered. These “gotchas” were mainly the result of integrating Hibernate Search into a legacy Hibernate application and were only related to configuration – but, as you probably know, sometimes you can spend more time configuring a new technology than coding against it. :-)

Meanwhile, you can find some tutorials and examples by simply plugging “Hibernate Search” into your favorite Internet search engine.


The Performance Zone is brought to you in partnership with AppDynamics.  See Gartner’s latest research on the application performance monitoring landscape and how APM suites are becoming more and more critical to the business.

Topics:

Published at DZone with permission of Tim Kitchens, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}