This may be necessary for further work, such as type-safe multi-valued projections, multi-valued field sorts, and more immediately stored fields in Lucene. So we should at least make sure that any multi-valued field will be declared as such, so that if we need this information in a later version of Hibernate Search, we can have it without backward-incompatible changes. If we never need this information, well, we can always relax the rules later.
Make the mapper tell the backend when nodes are to be considered as implicitly multivalued because of a multi-valued {{@IndexedEmbedded}}, or because of a {{ContainerValueExtractor}}.
Check at runtime that each field only has one value if it’s not marked as multi-valued.
~ Do not allow sorting on a multi-valued field in the Lucene backend, and maybe in the ES backend too (depending on whether it works or not). ~ => Actually no, we'll just use min/max sorts by default, just like Elasticsearch does. See HSEARCH-3103.
~ Do not allow projection on a multi-valued field for now.
Also see https://hibernate ~ => Actually it's a bit complicated, we'll handle that we we address multi-valued projections . atlassian.net/projects/ See HSEARCH /versions/28500/tab/release - report-todo 3391. |
|
