I read that Hibernate search does hit the DB when we search for indexed entities and that this can be avoided only when projections are used. I had the following questions based on this.

1. If Hibernate search does hit the DB for every search, then how does it give better performance than a normal DB query?

2. If I use Store.YES for the indexed field, the data is available in the index. Even then why does Hibernate hit the DB when searching for it?

3. Suppose my indexed entity has @IndexedEmbedded annotations for including related entities. If an indexed field changes in one of these related index. Will the whole lucene index be updated or only the section for this field be updated?

4. Suppose I index a collection of entities. Will the automatic updation of indexes work even if I retrieve data using projections?

Thanks in advance.

-Seema

Hi,


Hibernate Search does not search against the database. Per default Search will execute the search against the Lucene index to determine the entity ids which match the search query. Then it will load this entities from the database using plain old Hibernate. The advantage of course is that you always work with manages objects. The benefit of Lucene is that it is a freetext search engine. It offers functionality like wildcard search, fuzzy search, proximity search, etc. All this is not available to you in a normal DB query. The LIKE queries you would use in a direct DB query are just not as powerful and perform not as well as Lucene queries.
If you don't need fulltext search capabilities you can of course use HQL instead. In fact nothing stops you using a mixed apporach - where you use HQL for 'traditional' queries and Hibernate Search for fulltext queries.


Because the aim is to work with managed entities. The developer does not have to shift his programming paradigm.


Lucene Documents can not be updated. Effectively the document gets deleted and reinserted. That's just the way Lucene works.


Yes.

--Hardy

Thanks for the responses. I understand that to get benefit from using Store.YES, I must use projections instead of this approach. I went through the documentation about projections, but few things were not clear.


- If I use this option with projection, will it cause a DB hit since I'm getting back a managed entity. If yes, then what is the difference between this and the no-projection approach?



- Does this mean that if my indexed entity or its associated entity(@IndexedEmbedded) has a collection valued property, I cannot retrieve it?

Thanks,
Seema

If you just use FullTextQuery.THIS there is effectively no real difference to running a 'normal' Search query. It could make sense to use it in case you also want access to BOOST or SCORE. Projecting on THIS will not save you the db hit (even though with proper Hibernate caching your object might be in the second level cache)


You can project on simple properties, but you won't get back a whole collection.

--Hardy