This will throw an exception, because the field bridge for id cannot be guessed. However, id is not relevant in this case. Only the field foo gets indexed embedded into A.
A reminder from IRC chat: current Hibernate Search versions actually index the id of embedded components as well, and some users rely on that.
We agreed this shouldn't happen by default, but that is a semantic change that should be folded in the 5.0 stream.
So should we disable this then for Search 5? +1 from me
, so what are we saying here? If you use indexed embedded and the embedded entity itself is not indexed, then a potential @Id is ignored and to include this field into the index you need to add a @Field. If the embedded entity is indexed, the @Id or @DocumentId property gets automatically added. Correct? Or would be require a dedicated @Field for including the id of an embedded entity, no matter what?
If we want to change this, I guess now would be a good time.