I have a project that is currently using Compass. But as Compass is dead and falls further behind Lucene I'd like to possibly switch over to Hibernate Search. We're using Hibernate as our ORM, may as well use Hibernate's provided Lucene integration.

Compass has the @SearchableReference annotation. It puts into the index the id of the associated object, but not any of the object's field values.

Is there a way to do the same thing with Hibernate Search? We have some instances where we're using the associated object IDs.

I suppose I could use @IndexedEmbedded and only have @DocumentId on the associated object, but that doesn't seem right. Or could I use @Field with a bridge that pulls the id out of the associated object? Would work with ToMany associations?

Suggestions?

Hi,
I didn't know about @SearchableReference, and no there isn't a similar feature in Hibernate Search. I think you might trick the system by using a @ClassBridge (?)

Could you describe the use case? find it quite puzzling.

To be fair I never did a full comparison vs. Compass, it would be great if you could list any other gaps you find in your migration: maybe we can implement some or compile a guide for more people looking forward to move on.

The use case is Bar may be a large, complex object. When I search Foo, I want to filter on the associated Bars - not the values within the Bars, but which ones are attached to Foo. And I don't want to pull all the fields from Bar up into Foo's index. In our user interface, we do this with a select menu; the user selects one or more Bars and their IDs get added to the Lucene query against the Foo object. Make sense?

@SearchableReference is very much like @IndexedEmbedded, except the only field that gets embedded is the @DocumentId.

Now that I've read the Hibernate Search documentation a bit more, I think using @IndexedEmbedded(includePaths ={"id"}) would do the same thing as @SearchableReference. Unfortunately, "includePaths" is new with Hibernate Search 4, and we're still using Hibernate 3.

- Jasen.