I realize that it does not matter much if I store several fields (from my object graph) in the Lucene index. The HQL-query following shortly after the Lucene index-lookup still selects on those fields and joins on those associations although it really should not have to (all data should be available already).

Projections will let me avoid hitting the DB, but forces me to populate the entire object graph myself (or is there some clever way that I don't know of?)

To avoid DB-roundtrips (and expensive joins) it would be insanely nice to have this support in Hibernate Search. Is it in the pipeline or is it already supported (in some way that I haven't found out yet)?

Thankful for feedback on this,
Tobias

You understand that instead of DB-Roundtrips and expensive joins, you would end up with Index-Roundtrips (no joins but more roundtrips) :)

Yes ... of course. :) Still I think that would be a gain in our application, certainly so when the application layer is distributed while the backing DB is not. But we there's of course alot of other options to avoid hitting the db.

Thanks for feedback anyway. Our team enjoy the simplicity of Hibernate Search much. Thanks.

If you really need that, I think a local MySQL DB (local to your app deployment), replicated from a master DB is more what you're looking for. Isn't it?