For people working with Hibernate to manage their objects persistence, Hibernate search is a real savior.
After trying to develop similar functionality (collecting all objects changes and sending them to a full text search engine upon transaction commit) you find out pretty fast that there are lots of pitfalls out there.
On the other hand Solr has its own advantages (like 1:m facets for example if you need it) which make it a suitable decision on some scenarios.
So if I work with Hibernate as the JPA provider and index my objects on Solr, how can these components be integrated together?
可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
回答1:
In case you want to use them both together is turns out it is possible although it will require some programming work.
The idea is to work with Hibernate Search to do all the hard work and then collect the objects's changes and forward them to Solr.
This can be done either by configuring Hibernate Search to work with JMS or by implementing the BackendQueueProcessor class and registering it as the hibernate search processor.
If you wish to check out a working example, check out hibernate_search_solr_integration.
Just remember that it's just a concept demonstration and you will probably need to handle lots of issues such as connectivity failure, sync problems, thread concurrency, soft commit optimizations, etc...