A typical pattern is to use an EntityBase mapped superclass for all entities in the application. In this class the id-handling (i.e. the primary key) is defined for all entities as well as some common utilities such as ... toString etc.

Suppose we have two entities called Foo and Bar, both inheriting from EntityBase, and that there exists a 1-many-relation from Foo to Bar, i.e. "Foo has Bars".

Suppose we want to index Foo with hibernate search. This we do by annotating the Foo class with @Indexed. We also add a @DocumentId on the id in EntityBase. Now we add a @Field to all fields in Foo we like to have in the index. By examining with luke all seems fine up to this point.

Now, when using @IndexEmbedded on the relation to Bar and adding a desired field in Bar to the same index we also ... unfortunately gets the id for the Bar entity indexed. This as a consequence of having the @DocumentId in the mapped superclass.

Is this the correct behavior really? I never added a @Indexed to Bar. I am just reaching it via "embedded" ... so I can't see why an inherited @DocumentId would at all matter in the embedded class.

Bug or by design?

/Tobias

I realize that I of course can work around this by breaking my pattern and override the id in Foo ... also moving down the @DocumentId to Foo. But it would be nice if I didn't have to.

It is by designed, since @DocumentId really means 2 things: it's the id and it is @Field(UNTOKENIZED, STORE.YES)

Is that much of a problem to have the data indexed?

Hi Emmanuel,

No it is not much of a problem since I can work around it. It was a bit unexpected though why I thought this discussion (with your answer) could shed some light on it.

Actually the situation is a bit more complex than I described in the simplified example. We have several entities that are reached via relations whose DocumentIDs now are added to the index. We already have a very big index why anything stored in it not carrying information (that we really need) just seemed like a waste.

But as I said, no problem.

Best regards,
Tobias

Note that the idea of having a technical superclass to handle common entity needs is more of an anti-pattern than a pattern specifically because of such issues.

Thanks for your feedback! I hear you. Superclass-antipattern soon gone.