We're updating the issue view to help you get more done. 

Keep track of which field may be multi-valued and force bridges to declare fields as such

Description

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. => Actually it's a bit complicated, we'll handle that we we address multi-valued projections. See HSEARCH-3391.

Environment

None

Status

Assignee

Yoann Rodière

Reporter

Yoann Rodière

Labels

None

Suitable for new contributors

None

Feedback Requested

None

Fix versions

Priority

Major