[hibernate-issues] [JIRA] (HSEARCH-3971) Mapping an entity differently based on a discriminator

[Yoann Rodière (JIRA)]

Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A58fa1ced-171a-4c00-97e8-5d70d442cc4b ) *created* an issue

Hibernate Search ( https://hibernate.atlassian.net/browse/HSEARCH?atlOrigin=eyJpIjoiZDRhYzJiOTE1MDA0NGUwMWI5YTQ5NzRmMjMyZWJiOGUiLCJwIjoiaiJ9 ) / New Feature ( https://hibernate.atlassian.net/browse/HSEARCH-3971?atlOrigin=eyJpIjoiZDRhYzJiOTE1MDA0NGUwMWI5YTQ5NzRmMjMyZWJiOGUiLCJwIjoiaiJ9 ) HSEARCH-3971 ( https://hibernate.atlassian.net/browse/HSEARCH-3971?atlOrigin=eyJpIjoiZDRhYzJiOTE1MDA0NGUwMWI5YTQ5NzRmMjMyZWJiOGUiLCJwIjoiaiJ9 ) Mapping an entity differently based on a discriminator ( https://hibernate.atlassian.net/browse/HSEARCH-3971?atlOrigin=eyJpIjoiZDRhYzJiOTE1MDA0NGUwMWI5YTQ5NzRmMjMyZWJiOGUiLCJwIjoiaiJ9 )

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%3A58fa1ced-171a-4c00-97e8-5d70d442cc4b )

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=eyJpIjoiZDRhYzJiOTE1MDA0NGUwMWI5YTQ5NzRmMjMyZWJiOGUiLCJwIjoiaiJ9 ) Add Comment ( https://hibernate.atlassian.net/browse/HSEARCH-3971#add-comment?atlOrigin=eyJpIjoiZDRhYzJiOTE1MDA0NGUwMWI5YTQ5NzRmMjMyZWJiOGUiLCJwIjoiaiJ9 )

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.core&referrer=utm_source%3DNotificationLink%26utm_medium%3DEmail ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailNotificationLink&mt=8 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100140- sha1:fbb0377 )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hibernate-issues/attachments/20200727/7aa1dbcd/attachment.html