Message Title

Yoann Rodière updated an issue

HSEARCH-2055

I added a list of use cases to the ticket description.

Change By:	Yoann Rodière

Creating this issue to capture ideas/discussions around "FB 2.0".

* For index-embedded collections we need to keep the tree structure so we can properly feed ES
* ...

---

Identified use cases for bridges so far:

* Simple bridge that map a single value (the entity itself or a property) to a single field. It may be a builtin bridge (for instance for primitive types) or a custom one. Declaring the field name and setting field properties (index, docvalues, analysis, ...) directly when applying the bridge (in the mapping) may come handy.
* More complex bridge that maps a single value to multiple, pre-defined fields. Those fields should be declared somewhere, along with their properties (index, docvalues, analysis). Declaring the fields in the mapping would not be practical, since users would need to know about the exact content of the bridge implementation. The best place to declare the fields is probably inside the bridge implementation.
* More complex bridge that maps a single value to multiple, runtime-generated fields ("dynamic" fields). For instance the field names could be extracted from a string in the entity, and thus could not be declared before indexing. Those fields should be declared somewhere, along with their properties (index, docvalues, analysis), and the only place we can do that is inside the bridge implementation.

Add Comment

This message was sent by Atlassian JIRA