The {{org.hibernate.search.bridge.impl.BridgeFactory.getContainerType(XMember, ReflectionManager)}} method, responsible for determining the container type which will be used among others in {{org.hibernate.search.bridge.impl.BridgeFactory.getFieldBridgeFromBridgeProvider(BridgeProvider, ExtendedBridgeProviderContext, ContainerType)}}, relies on an {{@IndexedEmbedded}} annotation being present on the property.
This means in particular that array/iterable/map field bridges will only be affected to a property if this property carries both a {{@Field}} and a {{@IndexedEmbedded}} annotation.
**But** when you want to index an array of strings, for instance, putting an {{@IndexedEmbedded}} annotation on the property makes no sense, because the purpose of this annotation is to "allow[...] queries involving associated objects properties". Also, the documentation exclusively refers to this annotation in the context of {{@Embeddable}}s or entities, with no word about array bridges.
Furthermore, such practice causes trouble when trying to create an Elasticsearch mapping, as it results in the Elasticsearch property for the embedded and the Elasticsearch property for the Field having the same name.
Maybe we should drop this requirement of having an {{@IndexedEmbedded}} annotation for the array/iterable/map bridge to be affected correctly?
This will probably require some changes the the {{@IndexedEmbedded}} code, to make sure that the container type will be ignored if the {{@IndexedEmbedded}} is absent.
Then (in 6.0?), we may also consider checking for name conflicts between {{@IndexedEmbedded}} and {{@Field}} |
|