I would like to index data about an entity and IndexEmbedded entities into a top level “all” field, but I don’t see a way to not index using that doesn’t result in the path including the nested object name. Is there a way to remove the prefix that is used for IndexEmbedded entities such that their information is indexed at the root level without it?
There is no built-in way to do that, no. @IndexedEmbedded fields are necessarily placed in an “parent” object field corresponding to the @IndexedEmbedded.
One way to create an “all” field would be to not use mapping annotations, but instead write a custom bridge for each entity, and manually do the job of extracting information from entities and pushing it to your single field. That’s a lot of work and most people won’t want to do that.
Alternatively, if you’re using the Elasticsearch backend, you could define your own value binder that assigns a native Elasticsearch mapping to your field. That native mapping could rely on Elasticsearch’s “copy_to” feature, and then you could search on that “copy” field.
But really, I’d challenge the need for such an “all” field to begin with. When searching, you can simply target multiple fields in the same predicate. So it would be enough for you to keep a list of all fields in a given entity, and pass that list to .fields(...) when searching. Theoretically you could even build such a list of fields after bootstrap by inspecting the metamodel.
Eventualy we’ll add a way to assign “groups” to fields, so that you can just reference the “all” group when searching and Hibernate Search will automatically target the corresponding fields, and maybe one day a way to materialize groups of fields with a feature similar to Elasticsearch’s “copy_to”. But we’re not there yet.
I was thinking that the custom TypeBridge would be what is required for this but you are right, ultimately my goal is to be able to support searching across all fields in the index. In a previous version of hibernate we accomplished this by inspecting the index and getting all fields for that index. Inspecting the metamodel appears to almost get me there as this lists all static fields but we also have some dynamic fields as well. I may be able to rethink the use of dynamic fields to accomplish this differently but the metamodel suggestion get’s me most of the way there.
1 Like