When I'm indexing objects in my application I would like to store in the index some of the attributes of the object's associations. I need to store them in the index because I need a fast retrieval of those attributes. What is the best approach for doing this?

1) store the object relationships in lucene. This seems like the easiest and fastest approach.
2) store the object relationships in db
3) store the object relationships in something separate like a fast key-value store

Any other ideas on how I can store a set of attributes from a subset of objects from my app's object graph? Which solution should I use?

I don't get it. If you are using Hibernate your objects (including all relations) are already in the database anyways, right? If you use the default Hibernate Search behavior you will retrieve the object with all its relations.
Of course there is also projections. Maybe that's what you are after. In this case it might make sense to add additional data into the Documents.
Also, have you read the documentation about @IndexedEmbedded?

--Hardy

Hardy, unfortunately @IndexedEmbedded doesn't work very well. Unfortunate because although Hibernate Search is a beautiful project that solves a need elegantly, the core concept behind it of managing and indexing objects and their dependencies is broken in a way that is critical to our needs. Basically, in order for @IndexedEmbedded to work, you have to either save/update all of your inter-dependent entities in 1 transaction or have a very low number of entities to save/update. This issue has been open for over 7 months with no resolution:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513

So today, if someone needs to retrieve fields of associated entities with the above condition in hibernate search, they have to make a decision. They could simply rely on hibernate search to return back the entity object because hibernate stores the Id. Then query the database for those fields. However, if there are many associated entities and/or a deep object graph, this could introduce tremendous strain and latency.

They could store those fields in a custom lucene field. Then use projections to retrieve that data. That would be easy and fast, but are they hurting normal query performance without adding great query capabilities? And the biggest problem is they have to manage the updating of the entities. If one of the dependent entities' fields changes, how does lucene get updated? Basically this is where the idea of Hibernate Search makes so much sense...

Or instead of storing those fields in lucene, you could store it in a separate key-value store... getting the cache-like speed benefits without unnecessarily greatly expanding lucene's index. But, of course, you still have to then manage when those values get updated.