Yoann Rodière (
https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%...
) *created* an issue
Hibernate Search (
https://hibernate.atlassian.net/browse/HSEARCH?atlOrigin=eyJpIjoiZDRhYzJi...
) / New Feature (
https://hibernate.atlassian.net/browse/HSEARCH-3971?atlOrigin=eyJpIjoiZDR...
) HSEARCH-3971 (
https://hibernate.atlassian.net/browse/HSEARCH-3971?atlOrigin=eyJpIjoiZDR...
) Mapping an entity differently based on a discriminator (
https://hibernate.atlassian.net/browse/HSEARCH-3971?atlOrigin=eyJpIjoiZDR...
)
Issue Type: New Feature Assignee: Unassigned Components: mapper-pojo Created: 27/Jul/2020
03:39 AM Fix Versions: 6.1 Priority: Major Reporter: Yoann Rodière (
https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%...
)
Follow-up on HSEARCH-3311 (
https://hibernate.atlassian.net/browse/HSEARCH-3311 ) Pull
Request Sent.
In some cases, one could benefit of mapping an entity differently depending on
There are two use cases to distinguish:
* I want a different set of fields depending on a discriminator. This could be solved by
including all fields in the schema, but populating them only when needed at runtime: e.g.
only index largeTextField when entityState is ACTIVE , but not when it's ARCHIVED.
* I want the same fields, but configured differently depending on a discriminator. This
could be solved by mapping the same entity type to multiple indexes ( HSEARCH-3683 (
https://hibernate.atlassian.net/browse/HSEARCH-3683 ) Open ) with *a different schema*
(not included in HSEARCH-3683 (
https://hibernate.atlassian.net/browse/HSEARCH-3683 ) Open
), and creating the documents in the relevant index at runtime ; e.g. map
"BlogPost" to blogposts_fr and blogposts_de , use a different analyzer on the
text field in each index, and route blog posts with language = FR to blogposts_fr , blog
posts with language = DE to blogposts_de.
Use case 1: enable/disable fields based on a discriminator
----------------------------------------------------------
Both use cases could be addressed with the concept of "groups" introduced in
HSEARCH-3903 (
https://hibernate.atlassian.net/browse/HSEARCH-3903 ) Open. The user would
provide a component that enables or disables "groups" dynamically, based on the
state of the entity. All the groups that *can* be selected would be included in the index
schema, and when indexing some fields would get enabled or not based on the dynamic group
selection.
This would provide a feature similar to the AlternativeBinder , but much more powerful.
There is one unknown, though: how would @IndexedEmbedded.includeGroups interact with the
dynamic group selection? If dynamic group selection is overridden by
@IndexedEmbedded.includeGroups , it will likely not work as intended for the
"multi-language" use case of AlternativeBinder. If dynamic group selection
ignores @IndexedEmbedded.includeGroups , it will become impossible to exclude dynamically
enabled fields from @IndexedEmbedded.
Maybe we should separate the two concepts, e.g. @GenericField(groups = ..., dynamicGroups
= ...) ?
Or maybe we should assign a static group to the "dynamic group resolver": the
resolver and all corresponding fields would be included in the schema if the
resolver's assigned static group is included, even if the field's (dynamic) groups
are not included. Then it would be the user's responsibility to make sure static and
dynamic groups use different names, so as not to include dynamic groups statically by
mistake.
Use case 2: route to a different index with a different schema based on a discriminator
---------------------------------------------------------------------------------------
This should only be a matter of building upon what is described above and the work done in
HSEARCH-3683: when declaring the indexes an entity type is mapped to, we would also
declare the groups of field that are enabled for each index. Then at runtime, when an
entity is routed to an index, it would use the appropriate mapping.
(
https://hibernate.atlassian.net/browse/HSEARCH-3971#add-comment?atlOrigin...
) Add Comment (
https://hibernate.atlassian.net/browse/HSEARCH-3971#add-comment?atlOrigin...
)
Get Jira notifications on your phone! Download the Jira Cloud app for Android (
https://play.google.com/store/apps/details?id=com.atlassian.android.jira....
) or iOS (
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=Em...
) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100140- sha1:fbb0377 )