Originally posted by Darya Akbari:
I only know the classical core Hibernate. Do you think that data manipulation like delete, update and insert play a role for Hibernate Search?
No, they remain a part of the core of Hibernate. Hibernate Search adds an integration with
Lucene to allow "free text" searching capabilities. You don't use Hibernate Search for CRUD operations - you do those with Hibernate.
Some background: What is the difference between a "free text" search and a SQL/HQL select? A select statements searches one mapped entity based on known properties using well defined rules. For example consider the following HQL:
This searches for all foo objects whose name contains the characters 'blah'.
In an information retrieval system like Lucene you don't need to define that your search is only against foo objects, it could be against anything that is contained in an index. So I could index every table in my database in one index. I also don't need to define that I am only searching against the name field, I can search accross all indexed fields.
So why use select statements at all given information retrieval systems like Lucene exist? One reason is the overhead of indexing. If you let Hibernate index as it goes thats an bunch of extra work to do every time I perform a CUD operation. This overhead (and other considerations) also mean the indices can (in fact, probably will) be out of date. Hibernate Search in a clustered environment for example uses JMS to trigger index writes. A last possibility is the need to limit what the user can see. A simple use case could be selecting all foo objects created by me. "free text" searching is often too free.
So, Hibernate Search is
just about free text search. When it comes to normal CRUD operations, it is Hibernate itself that you would use.