Hibernate Search 3.2 has been in development close to a year and now we are releasing it :) Instead of giving you a list of new features, let me highlight a couple of use cases we now cover:
Defining index mappings depending on customer / deployment
The primary way to express index mappings in Hibernate Search is via annotations. This works 95% of the time, but in some cases you want to adjust what gets indexed and how in a more fine grained way. For example:
- you deliver the same application to different customers and want to give them the opportunity to configure some of the available indexed properties
- you deploy the same domain model in different apps where each needs specific search capabilities
To achieve this, we have introduced an easy to use, easy to read fluent programmatic API to express index mappings. Check out the programmatic API in the reference documentation or this blog entry.
Index/reindex my data easy and fast
In Hibernate Search, there has been a couple of best practices to initially index your data. You needed to read your data from the database in batch, call the index operation, flush and clear the session and move on to the next batch.
Forget that now. We have a super easy API to index or reindex your data (as simple as two method calls). You can also configure how indexing is done via an intuitive fluent API (yes we've catched the fluent API virus and you haven't seen the end of it). Not only is the new approach easy to use but it's also massively faster than the previously recommended best practices. We highly recommend people to move to this new approach.
Check out the reference documentation or this blog entry for more info.
I can't use JMS, but I need index clustering
Let me first state that setting up a JMS queue is super simple and trivial in any of the modern application servers ( esp JBoss AS :) ) and you get tons of benefits from it (reliability etc). Of course, if you like to waste time and build your own stack on top of Tomcat or equivalent, too bad for you.
Anyways, you can now use an alternative approach to JMS for clustering. We now support raw JGroups communications between cluster members.
My sysadmin needs a way to see what indexing operation have failed and restart them
Luckily that does not happen often but when indexing failures happen, we need to do something about them.
You now have access to an API to listen to indexing errors and process them as you please. The default implementation logs the error but you can easily decide to push the errors to some queue for display or replay, send a message via SNMP etc etc. The actual error is provided as well as the list of entities that should have been processed (quite handy for replay).
I have a single instance updating the index, can I make it faster?
Yes, if a single instance of Hibernate Search is responsible to update the index, we can speed up things. Simply add
hibernate.search.[default|index name].exclusive_index_use true
What else?
Hibernate Search 3.2 runs on Hibernate Core 3.5 and JPA 2. And as always we did many more things for this release including various optimizations, bug fixes, simplifying the Hibernate Search settings (especially for dependencies), adding a simpler API for bridges.
Check out on the web site, download Hibernate Search or browse the reference documentation. We also have a migration guide from earlier versions of Hibernate Search.
PS: For the Maven users, JBoss has migrated to a new maven repository. Read this user guide to know more.
PPS: We are already on Hibernate Search 3.3. Stay tuned.
